UML: Unified Modeling Language

Marvin Zumbado

UML: Lenguaje Unificado de Modelado

• UML  se inicia como el "Método de Modelado Unificado" presentado por Booch y Rumbaugh en el Workshop sobre Casos de Uso OOPSLA'95 (Object-Oriented Programming Systems Languages and Applications) en Octubre de 1995.

• También en 1995 se une Ivar Jacobson a Rational Software Corporation. A este grupo de investigadores se le conocería como los "tres amigos”.

UML: Lenguaje Unificado de Modelado

• Desde la fecha de su creación hasta la actualidad UML ha tenido una evolución, de las cuales se puede mencionar:

• Noviembre de 1997, es aprobado por el OMG • 1998 aparece la versión UML 1.2 (revisiones

menores) • 1999 aparece la versión UML 1.3 • 2000 aparece la versión UML 1.4 (revisiones

menores) • 2001 aparece la versión UML 1.5• Sigue UML 2.0.

UML: Lenguaje Unificado de Modelado

• La técnica central en el UML es el Modelamiento en Objetos, el cual es un lenguaje que permite la especificación de clases, sus datos o atributos (privados) y métodos (públicos), herencia y otras relaciones entre las clases.

• El UML modela sistema mediante el uso de objetos que forman parte de él así como, las relaciones estáticas o dinámicas que existen entre ellos.

• UML puede ser utilizado por cualquier metodología de análisis y diseño orientada por objetos para expresar los diseños.

UML: Lenguaje Unificado de Modelado

• UML no es un método de desarrollo. • No le dice cómo pasar del análisis al diseño,

ni de este al código. • No son una serie de pasos que llevan al

desarrollador a producir código a partir de unas especificaciones.

• UML al no ser un método de desarrollo es independiente del ciclo de desarrollo.

UML: Lenguaje Unificado de Modelado

• Hay dos aspectos de "unificación" que UML logra:

• El primero es que efectivamente termina con muchas de las diferencias, entre los lenguajes modeladores de métodos previos.

•Segundo, unifica las perspectivas entre muchos diferentes tipos de sistemas (negocio vs software), fases de desarrollo (requerimientos, análisis, diseño e implementación), y conceptos internos.

CONCEPTOS BASICOS• PROGRAMACIÓN ORIENTADA A OBJETOS

• La programación orientada a objetos difiere de la programación por procedimientos tradicional, pues examina los objetos que son parte de un sistema. Cada objeto es una representación de alguna cosa o evento real.

•  • OBJETOS

• Los objetos son personas, lugares o cosas que son relevantes para el sistema bajo análisis. Los objetos podrían ser clientes, artículos, pedidos, etc. Los objetos también podrían ser pantallas GUI o áreas de texto en la pantalla.

CONCEPTOS BÁSICOS

• CLASES• Los objetos se representan y agrupan en clases

que son óptimas para reutilizarse y darles mantenimiento. Una clase define el conjunto de atributos y comportamientos compartidos por cada objeto de la clase.

• Las clases están representadas por rectángulos, con el nombre de la clase, y también pueden mostrar atributos y métodos de la clase en otros dos “campos” dentro del rectángulo.

•  

CONCEPTOS BÁSICOS

• HERENCIA• Las clases pueden tener hijos; es decir, una clase se puede

crear a partir de otra clase. En el UML, la clase original —o madre— se conoce como clase base. La clase hija se denomina clase derivada. Ésta se puede crear de tal manera que herede todos los atributos y comportamientos de la clase base.

• Metodos:• Los métodos se muestran al menos con su nombre, y

pueden mostrar sus parámetros y valores de retorno.

Algunas Herramientas

NombreOpen Source

Licenciamiento de Software

Comentario

Microsoft Visio No Comercial

Herramienta de diagramado con soporte UML

MyEclipse No Comercial Un Eclipse basado en IDE

Nclass Si  Una Herramienta de Open Source para crear diagramas de clase UML

KeY Si GPLHerramienta de verificación de Software para Programas en Java

Bloques básicos de construcción de UML•Elementos

▫Son abstracciones que actúan como unidades básicas de construcción

•Relaciones▫Son abstracciones que actúan como unión

entre los distintos elementos. •Diagramas

▫Los diagramas son la disposición de un conjunto de elementos, que representan el sistema modelado desde diferentes perspectivas

Elementos• Estructurales:

▫ son las partes estáticas de los modelos y representan aspectos conceptuales o materiales.

• Comportamiento: ▫ son las partes dinámicas de los modelos y representan

comportamientos en el tiempo y en el espacio. • Agrupación (1):

▫ son las partes organizativas de UML, establecen las divisiones en que se puede fraccionar un modelo

• Notación (1): ▫ son las partes explicativas de UML, comentarios que

pueden describir textualmente cualquier aspecto de un modelo.

RelacionesDependencia

Es una relación entre dos elementos, tal que un cambio en uno puede afectar al otro.

Asociación

Es una relación estructural que resume un conjunto de enlaces que son conexiones entre objetos.

Generalización

Es una relación en la que el elemento generalizado puede ser substituido por cualquiera de los elementos hijos, ya que comparten su estructura y comportamiento.

Realización

Es una relación que implica que la parte realizante cumple con una serie de especificaciones propuestas por la clase realizada (interfaces).

Diagramas• Los diagramas estáticos son:

▫Clases▫Objetos▫Componentes▫Despliegue.

• Los diagramas de comportamiento son: ▫Casos de Uso▫Secuencia▫Colaboración▫Estados▫Actividades.

Diagrama de Caso de Uso•Describen lo que hace un sistema desde el

punto de vista de un observador externo•El ¿Qué? más que el ¿Cómo?•Los actores son papeles que determinadas

personas u objetos desempeñan.•Los Casos de Uso se representan por medio de

óvalos y las líneas representan una asociación de comunicación.

•El estereotipo “<<” y “>>” concreta un paso más allá el tipo de relación existente entre 2 casos

Diagrama de Secuencia y Diagrama de Colaboración• Describen como los objetos del sistema

colaboran• Es la interacción que detalla como las

operaciones se llevan a cabo, qué mensajes son enviados y cuando, organizado todo en torno al tiempo.

• El tiempo avanza “hacia abajo” en el diagrama. • Los objetos involucrados en la operación se

listan de izquierda a derecha de acuerdo a su orden de participación dentro de la secuencia de mensajes.

•Los diagramas de colaboración son otro tipo de diagramas de interacción, que contiene la misma información que los de secuencia, sólo que se centran en las responsabilidades de cada objeto, en lugar de en el tiempo en que los mensajes son enviados.

Diagrama de Estados y Diagrama de Actividades•Los diagramas de estados muestran los

posibles estados en que puede encontrarse un objeto y las transiciones que pueden causar un cambio de estado. El estado de un objeto depende de la actividad que esté llevando a cabo o de alguna condición.

•Las transiciones son las líneas que unen los diferentes estados

•Los diagramas de actividades son básicamente diagramas de flujo adornados, que guardan mucha similitud con los diagramas de estados.

• Mientras que los diagramas de estados centran su atención en el proceso que está llevando a cabo un objeto, los diagramas de actividades muestran como las actividades fluyen y las dependencias entre ellas.

Vistas• Vista de Casos de Uso: describen el comportamiento

del sistema como lo verían los usuarios finales, los analistas y demás componentes del equipo de desarrollo.

• Vista de Diseño: clases e interfaces que conforman el vocabulario del problema y su solución. Da soporte a los requisitos funcionales del sistema, es decir los servicios que proporciona a los usuarios finales.

• Vista de Procesos: hilos y procesos que forman los mecanismos de sincronización y concurrencia del sistema. Da soporte al funcionamiento, capacidad de crecimiento y rendimiento del sistema.

Vistas (cont.)

•Vista de Despliegue: la topología hardware sobre el que se ejecuta el sistema. Da soporte a la distribución, entrega e instalación de las partes que conforman el sistema físico.  

•Vista de Implementación: componentes y archivos empleados para hacer posible el sistema físico. Da soporte a la gestión de configuraciones de las distintas versiones del sistema, a partir de componentes y archivos.

Críticas a UML• Su carencia de una semántica precisa, lo que ha

dado lugar a que la interpretación de un modelo UML no pueda ser objetiva

• No se presta con facilidad al diseño de sistemas distribuidos (transmisión, serialización, persistencia)

• UML sí acepta la creación de nuestros propios elementos para este tipo de modelado, incluso cuenta con la posibilidad de agregar comentarios en forma de notas en las cuales se puede detallar todo aquello que no pueda ser expresado

Resumen del proceso

•Iniciar y mantener reuniones con los usuarios finales del programa

•Construir la vista de Casos de Uso definiendo exactamente la funcionalidad que se va a incorporar en el programa

•Se definen clases y relaciones entre ellas. Se construye aquí la vista de diseño y la vista de procesos.

Resumen del proceso (Cont.)

•Se define la vista de despliegue, que define la arquitectura física del sistema, y la vista de implementación.

•Construir el sistema, repartiendo las tareas entre el equipo de programación.

•Buscar errores de programación, o incluso de diseño, corregirlos e ir sacando sucesivas versiones del programa

•Documentar y entregar el programa a los usuarios finales.

CONCLUSIONES• UML Es un lenguaje de modelado y no de programación.•  • El vocabulario y las reglas de un lenguaje como UML indican

cómo crear y leer modelos bien formados, pero no dice que modelos se deben crear ni cuando se deberían crear. Esta tarea corresponde al proceso de desarrollo del software.

•  •  • Detrás de cada símbolo en la notación de UML hay una semántica

bien definida, de esta manera un desarrollador puede escribir un modelo en UML, y otro desarrollador o incluso otra herramienta, puede interpretar ese modelo sin ambigüedad.

•  • UML esta pensado principalmente para sistemas con gran

cantidad de software.

MUCHAS GRACIAS