Objeto de Aprendizaje : Introducción a UML

INTRODUCCIÓN A UML

Lenguaje de Modelado Unificado

Qué es UML?

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.

Qué es UML?

UML es un Lenguaje de Modelado Unificado basado en una notación gráfica la cual permite: especificar, construir, visualizar y documentar los objetos de un sistema programado.

Este lenguaje es el resultado de la unificación de los métodos de modelado orientados a objetos de Booch, Rumbaugh (OMT: Object Modeling Technique) y Jacobson (OOSE: Object-Oriented Sotfware Engineering).

UML

UML es un lenguaje de modelado que sirve para visualizar, especificar , construir y documentar un sistema software.Lenguaje de modelado: “Lenguaje cuyo vocabulario y reglas se centran en la

representación conceptual y física de un sistema” (Booch, Jacobson y Rumbaugh).

UML para visualizar

Símbolos con semántica bien definida. UML transciende al lenguaje de programación. Modelo explícito, que facilita la comunicación.

UML para especificar

Especificar es equivalente a construir modelos que cumplan las condiciones de no ambigüedad y completitud.

UML cubre la especificación del análisis, diseño e implementación de un sistema software.

UML para construir

Es posible hacer corresponder con los lenguajes de programación (Java, C#, B.Datos, etc.).

ModeloUML

Ingeniería Directa

Ingeniería Inversa

CÓDIGO

UML para documentar

UML cubre la documentación de un sistema:– Requisitos – Arquitectura– Diseño– Código fuente– Planificación– Pruebas– Prototipos– Versiones

UML “aglutina” enfoques OO

UML

RumbaughJacobson

Meyer

Harel

Wirfs-BrockFusion

Embly

Gamma et. al.

Shlaer-Mellor

Odell

Booch

Pre- and Post-conditions

State Charts

Responsabilities

Operation descriptions, message numbering

Singleton classes

Frameworks, patterns, notes

Object life cycles

Historia de UML

Nov ‘97 UML aprobado por el OMG19981999

2000

UML 1.2

UML 1.3

UML 1.42001 UML 2.0

Revisiones menores

Actualizaciones de UML

UML 1.3 es una versión madura de UML a la que se le han añadido una serie de pequeñas revisiones, las cuales corrigen o mejoran la especificación base (UML 1.2).

UML 1.4 incorpora ciertas modificaciones sobre el estándar en base a los comentarios recogidos de los usuarios finales y de los fabricantes de software compatible con UML.

UML 2.0 promete la puesta a punto del estándar para poder integrarse con el desarrollo basado en componentes que demanda el mercado.

UML 2.0

Arquitectura: refinamiento del núcleo del estándar para que esté en consonancia con el resto de estándares del mercado.

Personalización: mejora de los mecanismos de extensibilidad y personalización.

Componentes: mejor soporte para el desarrollo basado en componentes (CORBA, EJB, COM+).

Mecanismos generales: nuevos mecanimos para el control de las versiones dentro del modelo, así como el intercambio de los metadatos del mismo con XMI (XML Metadad Interchange).

Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés

El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren otros modelos ...

Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos

Modelos y Diagramas

Modelos y Diagramas

Modelo: captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito.

Diagrama: representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos.

Vista de Diseño

Vista de Procesos

Vista de Despliegue

Vista de Implementación

Vista de los Casos de Uso

Organización de Modelos

Diagramas de UML

Use CaseDiagramsUse Case

DiagramsDiagramas de Casos de Uso

ScenarioDiagramsScenario

DiagramsDiagramas deColaboración

StateDiagramsState

DiagramsDiagramas deComponentes

ComponentDiagramsComponent

DiagramsDiagramas deDistribución

StateDiagramsState

DiagramsDiagramas de Objetos

ScenarioDiagramsScenario

DiagramsDiagramas deEstados

Use CaseDiagramsUse Case

DiagramsDiagramas deSecuencia

StateDiagramsState

DiagramsDiagramas deClases

Diagramas deActividad

Modelo

Mecanismos comunes en UML

Especificaciones. Es más que un lenguaje gráfico (semántica detrás de la notación).

Adornos. Detalles sobre un clase, nivel de acceso de sus métodos, notas.

Divisiones Comunes: Clase/Objecto o Interfaz/Implementación.

Extensibilidad. Estereotipos, valores etiquetados o restricciones.

Mecanismos comunes en UML

+Insert()+Update()+Delete()#GetNumPaginas() : int

-Paginas : int

«utility»Producto

Paginas : int

«utility»p1 : Producto

Paginas : int

«utility»p2 : Producto

IDataManaged

{orderById}

Definición de un producto gestionado desde base de datos

Casos de Uso

Casos de Usos

Un diagrama de Casos de Uso muestra la distintas operaciones que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuario u otras aplicaciones).

Es una herramienta esencial para la captura de requerimientos y para la planificación y control de un proyecto interactivo.

Casos de Usos

Los casos de Uso Se representa en el diagrama por una elipse que denota un requerimiento solucionando por el sistema.

Cada caso de uso de uso es una operación completa desarrollada por los actores y por el sistema en un diálogo.

El conjunto de casos de uso representa la totalidad de operaciones desarrolladas por el sistema.

Casos de Usos

Casos de Usos

Actor: Es un usuario del sistema, que necesita o usa alguno de los casos de uso. Un usuario puede jugar más de un rol. Un solo actor puede actuar en muchos casos de uso; recíprocamente, un caso de uso puede tener varios actores. Los actores no necesitan ser humanos pueden ser sistemas externos que necesitan alguna información del sistema actual.

Casos de Usos

También se puede encontrar tres tipos de relaciones, como son:

– Comunica (comunicates) Entre un actor y un caso de uso, denota la participación del actor en el caso de uso determinado.

Casos de Usos

Usa (uses): Relación entre dos casos de uso, denota la inclusión del comportamiento de un escenario en otro. Se utiliza cuando se repite un caso de uso en dos o más casos de uso separados. Frecuentemente no hay actor asociado con el caso de uso común.

Casos de Usos

Extiende (extends): Relación entre dos casos, denota cuando un caso de uso es una especialización de otro. Se usa cuando se describe una variación sobre el normal comportamiento.

Casos de Usos

Técnicas comunes de modelado:– Modelado del contexto del sistema (utilidad

similar a los DFD).– Modelado de los requisitos de un sistema.– Modelado del proceso de test y estrés del

sistema.

Diagrama de Clases

Conceptos básicos orientación a objetos

Clase Objeto Herencia Interfaz Polimorfismo de clases Clases y atributos estáticos Clases y atributos finales Clases y métodos abstractos

Diagrama de clases

Un diagrama de clases o estructura estática muestra el conjunto de clases y objeto importantes que forman parte de un sistema, junto con las relaciones existentes entre clases y objetos. Muestra de una manera estática la estructura de información del sistema y la visibilidad que tiene cada una de las clases, dada por sus relaciones con los demás en el modelo.

Diagrama de clases

Usos comunes del diagrama:

– Modelado del vocabulario del sistema.– Modelado de colaboraciones simples.– Modelado de un esquema lógico de base de

datos.– Modelado de un conjunto de clases de test.

Diagrama de clases

Clase: representa un conjunto de entidades que tienen en común propiedades, operaciones, relaciones y semántica.

Una clase es un constructor que define la estructura y comportamiento de una colección de objeto denominados instancia de la clase.

En UML la clase está representada por un rectángulo con tres divisiones internas, son los elementos fundamentales del diagrama.

Diagrama de clases

Atributo: Representa una propiedad de una entidad. Cada atributo de un objeto tiene un valor que pertenece a un dominio de valores determinado.

Las sintaxis de una atributo es:– Visibilidad <nombre>: tipo = valor { propiedades}

Donde visibilidad es uno de los siguientes:– + público.– # protegido.– - privado.

Diagrama de clases

Operación: El conjunto de operaciones que describen el comportamiento de los objetos de una clase. La sintaxis de una operación en UML es:

Visibilidad nombre (lista de parámetros): tipo que retorna { propiedades}

Diagrama de clases

Nombre de la clase

Atributos

Métodos

Diagrama de clases

Responsabilidades: Contrato u obligación de una clase, asignada en el momento del diseño.

Clase Producto:– Registrar el código de la publicación.– Mantener estructura del producto plantilla.

Diagrama de clases

Técnicas de modelado:– Modelado del vocabulario de un sistema a partir de

las descripciones funcionales.– Modelado de la distribución de responsabilidades en

un sistema.– Modelado de cosas que no son software (hardware,

personas, etc).– Modelado de tipos primitivos.

Diagrama de clases

Objeto: es una instancia de una clase. Se caracteriza por tener una identidad única, un estado definido por un conjunto de valores de atributos y un comportamiento representado por sus operaciones y métodos.

Asociación (rol, multiplicidad, calificador): representan las relaciones entre instancias de clase. Una asociación es una línea que une dos o más clases.

Diagrama de clases

Nombre: Identifica la asociación entre los objetos, caracterizándola.

Rol: Identificado como un nombre a los finales de la línea, describe la semántica de la relación en el sentido indicado. Cada asociación tiene dos roles; cada rol es una dirección en la asociación. El rol puede estar representado en el nombre de la clase.

Diagrama de clases

Multiplicidad: Describe la cardinalidad de la relación, es decir, cuanto objetos de esa clase pueden participar en la relación dada. Tipos:

Diagrama de clases

Dependencia: Es una relación donde existen entidades independientes y otras dependientes, lo que implica que cambiar el elemento independiente puede requerir cambios en los dependientes. Se representa con una línea punteada direccional, indicando el sentido de la dependencia.

Diagrama de clases

Diagrama de clases

Los tipos de asociaciones entre clases presentes en un diagrama estático son:– Asociación binaria.– Asociación n-aria.– Composición.– Generalización.– Refinamiento.

Diagrama de clases

Asociación Binaria: Representa una relación sencilla entre dos clases, no muy fuerte (es decir, no se exige dependencia existencial ni encapsulamiento). Se indica como una línea sólida que une dos clases.

Asociación n-aria: Es una asociación entre tres o más clases. Se representa como un diamante del cual salen líneas de asociación a las clases.

Diagrama de clases

Diagrama de clases

Composición: Es una asociación fuerte que implica:– Dependencia existencial. El elemento

dependiente desaparece al destruirse el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo.

– Hay una pertenencia fuerte. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene.

Diagrama de clases

– Los objetivos contenidos no son compartidos, esto es, no hacen parte del estado de otro objeto.

Se denota dibujando un rombo del lado de la clase que contiene a la otra en la relación.

Diagrama de clases

Diagrama de clases

Agregación: Relaciona una clase ya ensamblada con una clase componente. Es también una relación de composición menos fuerte (no se exige dependencia existencial) y se denota por un rombo sin rellenar en un o de los extremos.

Diagrama de clases

Diagrama de clases

Generalización: es un proceso de abstracción en el cual un conjunto de clases existentes, que tienen atributos y métodos comunes, es referido por una clase genérica a un nivel mayor de abstracción. La relación de generalización denota una relación de herencia entre clases. Se representa dibujando un triángulo sin rellenar en el lado de la superclase. La subclase hereda todos los atributos y mensajes descritos en la superclase.

Diagrama de clases

Diagrama de clases

Refinamiento: Es una relación que representa la especificación completa de algo que ya ha sido especificado con cierto nivel de detalle. Por ejemplo, una clase del diseño es un refinamiento de una clase de análisis.

Diagrama de clases

Diagrama de clases

Técnicas de modelado:– Modelado de dependencias simples.– Modelado de herencia simple.– Modelado de relaciones estructurales

(composiciones y agregaciones).– Modelado de comentarios.

Diagrama de clases

Diagrama de Interacción

Diagrama de interacción

Estos son modelos que describen como los grupos de objetos que colaboran en algunos ambientes. Por lo general, un diagrama de interacción captura el comportamiento de un único caso de uso.

Hay dos tipos de diagramas de interacción: diagramas de secuencia y diagramas de colaboración.


Un diagrama de secuencia muestra la interacción de un conjunto de objetos de una aplicación a través del tiempo. Esta descripción es importante porque puede dar detalle a los casos de uso, aclarándolos al nivel de mensajes de los objetos existentes, como también muestra el uso de los mensajes de las clases diseñadas en el contexto de una operación.


Elementos básicos del diagrama de interacción:– Objetos o actores para cada entidad.– Enlaces entre los objetos.– Procedimientos a invocar entre los objetos.– Mensajes entre los objetos.


Un objeto se representa como una línea vertical punteada (línea de vida), con un rectángulo de encabezado y con rectángulo a través de la línea principal que denotan la activación, es decir, el período de tiempo en el cual el objeto se encuentra desarrollando alguna operación.

El rectángulo de encabezado contiene el nombre del objeto y el de su clase, en un formato nombreObjeto: nombreClase. El envío de mensajes entre objetos se denotan mediante una línea sólida dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta.



Diagramas de Colaboración:– Es una forma de representar interacción entre los objetos,

es decir, las relaciones entre ellos y la secuencia de los mensajes de las iteraciones que están indicadas por un número A diferencia de los diagramas de secuencia, pueden mostrar el contexto de la operación (cuáles objetos son atributos, cuáles temporales, etc) y ciclos en la ejecución. Muestra como varios objetos colaboran en un solo caso de uso.



Técnicas de modelado:– Modelado dinámico del sistema.– Implementación de un caso de uso en concreto para

cada diagrama.– Modelado del flujo de control por ordenación temporal

(secuencia).– Modelado del flujo de control por organización

(colaboración).

Diagrama de Estados

Diagrama de estados

Diagrama de Estados:– Muestra el conjunto de estado por los cuales

pasa un objeto durante su vida en una aplicación junto con los cambios que permiten pasar de un estado a otro. Esta representado principalmente por los siguientes elementos:

Estado. Elemento. Transición.

Diagrama de estados

Estado: Identifica un período de tiempo del objeto (no instantáneo) en el cual el objeto esta esperando alguna operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos.

Diagrama de estados

Partes que componen un estado:– Nombre– Acciones de entrada y de salida.– Transiciones internas.– Subestados.– Eventos diferidos.

Diagrama de estados

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

– Condición que toma el 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.

Diagrama de estados

Transición: Es una relación entre estados de un fuente a un destino.

Partes que componen una transición:– Estado de origen.– Evento de disparo.– Condición de guarda.– Acción.– Estado de destino.

Diagrama de estados

Otros elementos:– Subestados. Secuenciales o no, resultan en una nueva

máquina de estados.– Estados de historia.– Estados de historia. Permiten a un conjunto de estados o

subestados de un objeto, recordar el estado que estaba activo en su última ejecución. Si no existe historia, se comenzaría por el estado inicial.

– Subestados concurrentes.

Diagrama de estados

Diagrama de estados

Técnicas de modelado:– Modelado de la vida de un objeto. Este tipo de

diagramas se asocian directamente a una clase.

Diagrama de Actividades


Un diagrama de actividades es un caso especial de un diagrama de estados en el cual casi todos los estados son estados de acción (identifican que acción se ejecuta al esta en él ) y casi todas las transiciones son enviadas al terminar la acción ejecutada en el estado anterior.

Generalmente modelan los pasos de un algoritmo y puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto.


Sirven para representar transiciones internas, sin hacer mucho énfasis en transiciones o eventos externos.

Los elementos que conforman el diagrama son: – Acción– Transición.– Objetos


Estado de Acción: representa un estado con acción interna, con lo menos una transición que indica la culminación de la acción (por medio de un evento implícito).– Permite modular un paso dentro del algoritmo. Se

representan por un rectángulo con bordes redondeados.


Estado de Actividad: Estado más general que permite su descomposición en otro diagrama de actividades interno, de nivel más bajo.– Su representación, en cuanto a la notación, es la

misma que el de Acción.


Casos especiales:– Estado inicial. Representa el punto de entrada del

diagrama de actividades.– Estado final. Su existencia depende de si el

diagrama es cíclico.– Ítem de decisión. Representado con un rombo,

permite tomar bifurcaciones condicionales.


Casos especiales:– Carriles o “Swim Lanes”. Permiten acotar el área a

las cuales las actividades están asociadas (departamentos, módulos del sistema, etc).

– Flujos con objetos. Hacer explícita la relación con una entidad en concreto.


Transición: Es la relación entre dos estados y se encuentran unidos por flechas; indicando que un objeto que está en el primer estado realizará una acción especificada y entrará en el segundo estado cuando un evento implícito ocurra y unas condiciones especificas sean satisfechas.


Tipos de transiciones:– Bifurcaciones condicionales. Permiten tomar

distintos caminos dentro del diagrama en función de una condición o “guarda”.

– División y unión. Permiten representar el paralelismo en la ejecución de actividades.



Técnicas de modelado:– Modelado de un flujo de trabajo o Workflow. Uso intensivo de

estados de actividad, swim lanes y bifurcaciones condicionales.

– Modelado de una operación concreta que resulta muy complicada. Uso intensivo de transiciones (simples o paralelas) y de estados de acción.

Diagrama de Componentes

Diagrama de componentes

Los diagramas de componentes describen los elementos físicos reemplazables del sistema y sus relaciones

Muestran las opciones de realización incluyendo código fuente, binario y ejecutable


Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. Pueden ser simples archivos, librerías, bibliotecas cargadas dinámicamente, etc.

Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente



Técnicas de modelado:– Modelado de ejecutables y bibliotecas.– Modelado de tablas, archivos y documentos.– Modelado y diseño de un API.– Modelado del código fuente.– Planificación de versiones ejecutables para su implementación

con Nant.

Diagrama de Despliegue

Diagrama de despliegue

Los diagramas de despliegue muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos

La vista de despliegue representa la disposición de las instancias de componentes de ejecución en instancias de nodos conectados por enlaces de comunicación.

Un nodo es un recurso de ejecución tal como– Dispositivos– Procesadores– Memoria

Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse.



Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse.

Esta vista permite determinar las consecuencias de la distribución y la asignación de recursos.




Técnicas de modelado:– Modelado de procesadores y dispositivos.– Modelado de distribución de componentes.

RUP: El Proceso Unificado de Rational

Proceso Unificado de Rational

Orígenes– Modelo original Objectory definido por Ivan

Jacobson (1987)– Rational Software compra la empresa de

Objectory (1995)– Surge la primera versión de UML (1997)– Se publica la primera versión del Proceso

Unificado de Rational - RUP (junio 1998)

Casos de uso

Dirigido por casos de uso– Se centra en la funcionalidad que el sistema debe poseer para

satisfacer las necesidades de un usuario (persona, sistema externo, dispositivo) que interactua con él

– Casos de uso como el hilo conductor que orienta las actividades de desarrollo

Casos de Uso

AnálisisRecopilar,

Clarificar y Validar los

requerimientos

Diseño

Realizar loscasos de uso

Pruebas

Verificar que sesatisfacen los casos de uso

<<realiza>> <<verifica>><<defineNecesidades>>

Arquitectura

Centrado en la arquitectura– Concepto similar a la arquitectura de un edificio

Varios planos con diferentes aspectos del edificio Tener una imagen completa del edificio antes que comience la construcción

– Arquitectura en software Diferentes vistas del sistema: estructural, funcional, dinámico, etc. Plataforma en la que va a operar Determina la forma del sistema

– Arquitectura: determina la forma del sistema– Casos de uso: determinan la función del sistema

Modelo que implementa

Iterativo e incremental– Descomposición de un proyecto grande en mini-proyectos– Cada mini-proyecto es una iteración– Las iteraciones deben estar controladas– Cada iteración trata un conjunto de casos de uso

Ventajas del enfoque iterativo– Detección temprana de riesgos– Administración adecuada del cambio– Mayor grado de reutilización– Mayor experiencia para el grupo de desarrollo

Estructura

Dinámica Ciclo: cada ciclo una nueva versión del producto Fase: Etapas de un ciclo que finalizan en un HITO Iteración: Proceso de ingeniería sobre una funcionalidad

limitada del sistema

Estática - Flujos de trabajo Artefactos Actividades Roles

Estructura

Roles QUIÉN? Actividades CÓMO? Artefactos QUÈ? Flujo de Trabajo CUÁNDO?

realiza

responsable dediseñador

diseño de casode uso

diagrama de secuencia

Roles

Definición del comportamiento y responsabilidades de los participantes

Propietario de una serie de artefactos

Recurso Rol Actividad Artefacto

Diseñador Diseño de Objetos DCAnalista Definición de CU DCUDominioDiseñador Diseño de CU DSFuncional

PatriciaJuanMónicaPedro

Actividades

Unidad de trabajo que puede ejecutar un individuo en un rol específico

Tiene un propósito claro y se expresa en términos de actualizar artefactos

La granularidad de la actividad es generalmente de horas o pocos días

Ejemplos de actividades– Planear una iteración (administrador del proyecto)– Encontrar caso de uso y actores (analista del dominio)– Revisión del diseño (probador)

Artefactos

Pieza de información producida, modificada y utilizada en un proceso

Productos tangibles del proyecto Utilizados por los roles como entrada para la

realización de sus actividades Resultado de las actividades realizadas por los roles Metamodelo: Clase rol tiene como métodos las

actividades y como parámetros los artefactos

Flujos de trabajo

Forma de describir significativamente la secuenciencias de actividades que producen resultados y las interacciones entre cargos

En términos de UML se puede utilizar: diagrama de actividades, de secuencia, de colaboración

En RUP hay nueve tipos de flujos de trabajo– De ingeniería

Negocio, Requerimiento, Análisis, Diseño, Pruebas, Liberación– De soporte

Administración del proyecto, Administración del cambio, Ambiente

Dimensión dinámica

Concepción Elaboración Construcción Transición

ciclofase

Iter. 1 Iter. 2 Iter. 3 Iter. 4 Iter. 5 Iter. 6

hito 1 hito 2 hito 3 hito 4

Hito: punto en el tiempo en donde se evaluan objetivoslogrados y se pueden tomar decisiones críticas

Desarrollo iterativo

Ciclo dedesarrollo 1

Ciclo dedesarrollo 2

Ciclo dedesarrollo n

Perfeccionarel plan

SincronizarArtefactos

Análisis Diseño Construcción Pruebas

Construcción

Fase de concepción

Objetivo: definir la razón de ser y el alcance del proyecto. Estudio de oportunidad.

– Visión = QUÉ + PARA QUÉ + CUÁNTO Actividades

– Especificación de los criterios de éxito del proyecto– Definición de los requerimientos – Estimación de los recursos necesarios– Cronograma inicial de fases

Artefactos– Documento de definición del proyecto

Fase de elaboración

Objetivo: establecer un plan de proyecto y una arquitectura correcta del sistema

Actividades– Análisis del dominio del problema– Definición de la arquitectura básica – Análisis de riesgos– Planificación del proyecto

Artefactos– Modelo del dominio– Modelo de procesos– Modelo funcional de alto nivel– Arquitectura básica

Fase de construcción

Objetivo: desarrollar el sistema a lo largo de una serie de iteraciones

Actividades– Análisis– Diseño– Codificación– Pruebas (individuales, de integración)

Education

Objeto de Aprendizaje : Introducción a UML