UML (Unified Modeling Language) es un lenguaje para especificar, visualizar, construir y documentar las diferentes etapas del desarrollo de software, así como para modelado de procesos de negocio u otros sistemas no-software. UML reúne una colección de las mejores prácticas en la ingeniería que han sido utilizadas con éxito para modelar sistemas grandes y complejos, ya que cubre tanto objetos conceptuales como los procesos de negocio y funciones del sistema, como también objetos concretos como clases en un lenguaje de programación, esquemas de base de datos y componentes reusables de software.
UML ha sido creado por los expertos en la metodología orientada a objetos tales como Grady Booch, Ivar Jacobson, y James Rumbaugh en Rational Software, utilizando información de otros importantes expertos en metodología, vendedores de software, y usuarios finales. Su objetivo era unificar los diversos sistemas que había y crear un lenguaje de modelado con las mejores características de cada uno.
El UML fue adoptado por el OMG (Object Management Group) como estándar en noviembre de 1997 y ha comenzado rápidamente a ser utilizado en el diseño, especificación, construcción, visualización y documentación de software.
La técnica central en el UML es el Modelamiento en Objetos que 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.
Etapas y actividades en el desarrollo OO basado en UML
En la versión definitiva de la metodología publicada por Booch, Rumbaugh y Jacobson se pueden tener en cuenta las siguientes etapas:
· Análisis de Requerimientos
· Diseño del sistema
· Diseño detallado
· Implementación y pruebas
Cada etapa consta de actividades que le dan cuerpo y los documentos que se esperan al final de cada una de ellas.
Elementos Notacionales de UML
Los elementos notacionales que presenta el UML pretenden ser un lenguaje común para el modelamiento de cualquier sistema y se agrupan en tipos de diagrama:
1. Diagrama de Clases
2. Diagrama de Objetos
3. Diagrama de Casos de Uso
4. Diagrama de Secuencia
5. Diagrama de Colaboración
6. Diagrama de Estados
7. Diagrama de Actividades
8. Diagrama de Componentes
9. Diagrama de Ejecución
PRESENTE Y FUTURO DEL UML
El UML no tiene propietario y está abierto para todos. Muchos metodologistas, organizaciones y vendedores de herramientas han comenzado a usarlo. Puesto que UML se construyó sobre la semántica y notación de Booch, OMT, OOSE, y otras metodologías líderes, ha incorporado mejoras de compañeros de UML y retroalimentaciones del público en general, la adopción del UML a nivel mundial ha de ser fácil.
Hay dos aspectos de "unificación" que UML logra. El primero es que efectivamente termina con muchas de las diferencias, a veces inconsecuentes, entre los lenguajes modeladores de métodos previos.
Segundo y más importante, 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.
EVOLUCION DEL UML
Aunque UML define un lenguaje preciso, no es una barrera a futuras mejoras en conceptos de modelamiento. Hemos visto muchas técnicas líderes, pero esperamos que futuras técnicas influyan en las versiones futuras de UML (cabe destacar que la versión actual del UML es 1.3). El UML actualmente espera ser la base de muchas herramientas, incluyendo aquellas de modelamiento visual, simulación y ambientes de desarrollo. El UML ha integrado muchas ideas disparatadas, su integración acelerará el uso de metodologías OO.
El desarrollo basado en componentes se aproxima y merece mencionarlo, éste es correlativo con las tradicionales técnicas OO. Mientras el uso de componentes está comenzando a incrementarse esto no significa que las técnicas basadas en componentes reemplazarán a las técnicas OO. Sólo hay sutiles diferencias entre la semántica de componentes y clases.
5.2 Vista estática.
La vista estática nos permite visualizar el comportamiento externo del programa; de esta forma conseguimos conocer qué es lo que debe hacer el programa independientemente de cómo lo haga y sabremos los elementos que interactúan con el sistema. Los elementos implicados en un diagrama de casos de uso son los casos de uso, las relaciones y los actores. Las relaciones y los casos de uso ya han sido explicados anteriormente y el papel del actor también ha sido comentado pero merece la pena detallarlo más: Un actor es un rol que interactúa con el sistema. Lo definimos como rol porque un actor puede ser tanto un usuario de la aplicación como otro sistema o dispositivos externos.
5.3 Vista dinámica.
Vistas dinámicas es un nombre general que engloba varias tecnologías relacionadas que comparten el objetivo en común de hacer que el análisis y la documentación del modelo sea más interactiva e intuitiva. Una de estas tecnologías permite recortar modelos y generar gráficos de sección sobre la marcha. Las vistas de sección, vistas de detalle y vistas de cota son tipos de vistas dinámicas. Atrás quedaron los días en que los diseños de MicroStation eran sólo vistas estáticas, sustituidos por la posibilidad de crear secciones inteligentes en vivo de una composición de diseño que se actualiza automáticamente (mediante el uso de símbolos de detalle con campos y vínculos inteligentes) a medida que evoluciona el diseño.
Creación de vistas dinámicas a partir de símbolos de detalle
Puede crear vistas dinámicas cuando crea símbolos de detalle en las hojas. Estas llamadas le permiten crear vistas de sección en la composición de diseño que están vinculadas a llamadas de sección colocadas en las hojas. Cualquier modificación al símbolo de detalle en la hoja se refleja en su vista guardada correspondiente en el modelo de diseño. De forma inversa, las modificaciones realizadas a la vista guardada en el modelo de diseño también se reflejan en su símbolo de detalle asociado en la hoja.
Control de secciones dinámicas con símbolos de detalle
Puede controlar una vista dinámica utilizando sus dimensionadores de edición. Seleccione la vista en el diálogo Vistas guardadas, active la columna Mostrar y seleccione el cuadro de vista guardada para ver los dimensionadores de edición de volumen de recorte. Cualquier modificación realizada a los dimensionadores de edición se reflejan en todos los símbolos de detalle que están asociados a esa vista.
Vinculación de vistas dinámicas como referencias para la composición de modelos y hojas
Puede vincular una vista guardada como referencia en una hoja. Los ajustes de visualización y las máscaras de nivel de la vista guardada se utilizan en la referencia. Si mueve un símbolo de detalle asociado con la vista guardada, cambiará la vista guardada en el modelo de diseño, y como la vista guardada se colocó en una hoja, también cambiará en la hoja. La potencia de las vistas dinámicas radica en que puede cambiar el símbolo de detalle y que se actualice la referencia automáticamente.
5.4 Diagramas PRIMER PARCIAL.
Tipos de Diagramas en UML
Grandes clásicos conocidos por todos, los diagramas de clases, distan mucho de ser los únicos definidos en el lenguaje. De hecho en la versión UML 2 existen trece (13) diagramas concretos y varias categorías de diagramas abstractos, creados como toda clase abstracta, para articular la presentación de los diagramas.
La siguiente figura UML muestra los tipos de diagramas:
Fig. 1 – Tipos de diagramas en UML2
En su momento detallaré cada uno de los tipos de diagramas, lo importante por ahora es señalar que existen dos grandes grupos: estructurales y de comportamiento; esto conforme a lo dicho sobre la presentación de modelos en UML.
Los diagramas estructurales presentan elementos estáticos del modelo, tales como clases, paquetes o componentes; en tanto que los diagramas de comportamiento muestran la conducta en tiempo de ejecución del sistema, tanto visto como un todo como de las instancias u objetos que lo integran.
Por otra parte, en la figura se ve que hay tres tipos de diagramas señalados en un color distinto: los diagramas de estructura compuesta, de tiempo y de resumen de interacción. Se han resaltado dado que son nuevos dentro del UML por lo que resultan ser de los menos conocidos. También aspiro a tener una descripción de ellos en los días por venir.
Hay que tener en cuenta, que cada diagrama sirve para documentar un aspecto distinto del sistema; el criterio para usarlos es el de tener algo que decir, una historia sobre nuestro sistema que debe ser contada; el tipo de diagrama que utilizaremos será el que nos dé mayor poder expresivo y solo muy difícilmente, la construcción de una serie de diagramas puede ser explicitamente ordenada por un método de desarrollo. Algunos sistemas simples serán bien documentados con pocos diagramas, en tanto que algunos sistemas grandes bien podrían beneficiarse de un conjunto mayor.
Entonces que valga la advertencia: no hacemos diagramas porque un método nos lo ordene, hacemos diagramas para contar algo importante de nuestro modelo, por lo que indicar que en un sistema haya que hacer tantos de tal o cual diagrama es una declaración objetable.
Diagramas de casos de uso: Un diagrama de casos de uso es un diagrama que muestra un conjunto de casos de uso con sus relaciones y los actores implicados. Es un diagrama que sirve para modelar la vista estática de un programa. La vista estática nos permite visualizar el comportamiento externo del programa; de esta forma conseguimos conocer qué es lo que debe hacer el programa independientemente de cómo lo haga y sabremos los elementos que interactúan con el sistema. Los elementos implicados en un diagrama de casos de uso son los casos de uso, las relaciones y los actores. Las relaciones y los casos de uso ya han sido explicados anteriormente y el papel del actor también ha sido comentado pero merece la pena detallarlo más: Un actor es un rol que interactúa con el sistema. Lo definimos como rol porque un actor puede ser tanto un usuario de la aplicación como otro sistema o dispositivos externos.
Diagramas de secuencia: Un diagrama de secuencia es un diagrama de interacción UML. Estos diagramas muestran la secuencia de mensajes que se van lanzando los objetos implicados en una determinada operación del programa. Dentro del diagrama los objetos se alinean en el eje X respetando su orden de aparición. En el eje Y se van mostrando los mensajes que se envían, también respetando su orden temporal. Cada objeto tiene una línea de vida donde se sitúa su foco de control. El foco de control es un rectángulo que representa el tiempo durante el que un objeto está activo ejecutando una acción. Con este sencillo esquema podemos visualizar la comunicación y sincronización bajo un estricto orden temporal de los objetos implicados en las distintas funcionalidades de un sistema.
Diagramas de clases: Un diagrama de clases es un diagrama que muestra un conjunto de clases y sus colaboraciones y relaciones. Estos diagramas sirven para visualizar las relaciones existentes entre las distintas clases y la forma en que colaboran unas con otras. Las relaciones entre las distintas clases son las relaciones comunes existentes en UML aunque con matices: Una asociación se traduce como que desde los objetos de una clase se puede acceder a los objetos de otra. Una dependencia se puede visualizar como que la clase utilizada usa parámetro o métodos de la clase que la utiliza. Una generalización se traduce como una herencia entre clases.
Diagramas de colaboración: Esencialmente es un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de colaboración muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de colaboración no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes.
Diagrama de Clases
Ejemplo de Diagrama de Clases
Diagramas de Objetos
Muestran un conjunto de objetos y sus relaciones, son como fotos instantáneas de los diagramas de clases y cubren la vista de diseño estática o la vista de procesos estática desde la perspectiva de casos reales o prototípicos.
Objetos
Análogo al diagrama de clases, muestra un conjunto de objetos y sus relaciones, pero a modo de vista instantánea de instancias de una clase en el tiempo.
Diagramas de Casos de Usos
Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus relaciones. Cubren la vista estática de los casos de uso y son especialmente importantes para el modelado y organización del comportamiento.
Casos de Uso
Muestra un conjunto de casos de uso, los actores implicados y sus relaciones. Son diagramas fundamentales en el modelado y organización del sistema.
Diagramas de Secuencia y de Colaboración
Tanto los diagramas de secuencia como los diagramas de colaboración son un tipo de diagramas de interacción. Constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar unos objetos a otros. Cubren la vista dinámica del sistema. Los diagramas de secuencia enfatizan el ordenamiento temporal de los mensajes mientras que los diagramas de colaboración muestran la organización estructural de los objetos que envían y reciben mensajes. Los diagramas de secuencia se pueden convertir en diagramas de colaboración sin perdida de información, lo mismo ocurren en sentido opuesto.
Secuencia
Son diagramas de interacción, muestran un conjunto de objetos y sus relaciones, así como los mensajes que se intercambian entre ellos. Cubren la vista dinámica del sistema. El diagrama de secuencia resalta la ordenación temporal de los mensajes, mientras que el de colaboración resalta la organización estructural de los objetos, ambos siendo equivalentes o isomorfos. En el diagrama de colaboración de la figura de la izquierda, se puede ver que los elementos gráficos no son cajas rectangulares, como cabría esperar, y en su lugar encontramos sus versiones adornadas. Estas versiones tienen como finalidad evidenciar un rol específico del objeto siendo modelado. En la figura encontramos de izquierda a derecha y de arriba abajo un Actor, una Interfaz, un Control (modela un comportamiento) y una Instancia (modela un objeto de dato).
Colaboración
Diagramas de Estados
Muestran una maquina de estados compuesta por estados, transiciones, eventos y actividades. Estos diagramas cubren la vista dinámica de un sistema y son muy importantes a la hora de modelar el comportamiento de una interfaz, clase o colaboración.
Estados
Muestra una máquina de estados, con sus estados, transiciones, eventos y actividades. Cubren la vista dinámica de un sistema. Modelan comportamientos reactivos en base a eventos.
Diagramas de Actividades
Son un tipo especial de diagramas de estados que se centra en mostrar el flujo de actividades dentro de un sistema. Los diagramas de actividades cubren la parte dinámica de un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando el flujo de control entre objetos.
Actividades
Tipo especial de diagrama de estados que muestra el flujo de actividades dentro de un sistema.
Diagramas de Componentes
Muestra la organización y las dependencias entre un conjunto de componentes. Cubren la vista de la implementación estática y se relacionan con los diagramas de clases ya que en un componente suele tener una o más clases, interfaces o colaboraciones
Diagramas de Despliegue
Representan la configuración de los nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. Muestran la vista de despliegue estática de una arquitectura y se relacionan con los componentes ya que, por lo común, los nodos contienen uno o más componentes.
Diagrama de Despliegue
Hoy habia 2 visitantes (3 clics a subpáginas) ¡Aqui en esta página!
