INTRODUCCION UML

Introducción: UML

El Lenguaje de Moldeamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software. UML entrega una forma de modelar cosas conceptuales como lo son procesos de negocio y funciones de sistema, además de cosas concretas como lo son escribir clases en un lenguaje determinado, esquemas de base de datos y componentes de software. 

Objetivos 

• UML es un lenguaje con un alcance muy grande y 

que cubre diversos conjuntos de dominios 

arquitectónicos en el diseño de aplicaciones.

• Por ello, no todas sus capacidades de modelados 

son necesariamente útiles en todos los dominios o 

aplicaciones.

• UML permite seleccionar sólo aquellas partes del 

lenguaje que sean realmente útiles.

2.13 Diagrama de Interacción global

Muestran una interacción, que consiste de un conjunto de objetos y sus relaciones, incluyendo los mensajes que puedan ser realizados entre ellos. Son importantes para modelar los aspectos dinámicos de un sistema.

Características:

Contienen objetos, enlaces y mensajes.

Representan secuencia de intercambios y mensajes entre los roles que participan y se relacionan con un sistema.

 

2.12 Diagrama de tiempos

Los diagramas de tiempo son una representación especial de interacción que se enfoca en el tiempo de los mensajes enviados entre objetos. Se pueden usar estos diagramas para mostrar restricciones detalladas sobre el tiempo, o para mostrar los cambios con líneas de vida respecto al tiempo.

Características:

Los diagramas de tiempo son generalmente utilizados con sistemas en tiempo real o en sistemas embebidos.

Examinando un diagrama de tiempos, se puede determinar los estados, nivel alto o nivel bajo, de cada una de las señales en cualquier instante de tiempo especificado, y el instante exacto en que cualquiera de las señales cambia de estado con respecto a las restantes.

2.11 Diagrama de colaboración

Es un diagrama de interacción que enfoca las interacciones y los enlaces entre un grupo de objetos . Ubicándose éste en el espacio mostrando los objetos, sus enlaces y los mensajes entre ellos.

El Diagrama de Colaboración presenta una alternativa al diagrama de secuencia para modelar interacciones entre objetos en el sistema.

Mientras que el diagrama de secuencia se centra en la secuencia cronológica del escenario que estamos modelando, el diagrama de colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario. 

Los objetos se conectan por medio de enlaces, cada enlace representa una instancia de una asociación entre las clases implicadas.

Características:

Representa los efectos de un objeto dado durante un escenario.

Los objetos se conectan por medio de enlaces, los enlaces representan una instancia de una asociación entre las clases implicadas.

No muestra el tiempo como una dimensión aparte, por lo que se hace necesario etiquetar con números de secuencia tanto la secuencia de los mensajes como los hilos concurrentes.

2.10 Diagrama de secuencia

Un diagrama de secuencia muestra un conjunto de mensajes, dispuestos en una secuencia temporal. Cada rol en la secuencia se muestra como una línea de vida, es decir, una línea vertical que representa el rol durante cierto plazo de tiempo, con la interacción completa.

 El diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos.

Características:

Muestra la secuencia del comportamiento de un caso de uso.

Muestra como lo objetos interactúan entre ellos.

Es específico para un escenario.

Tiene dos ejes: un eje vertical que muestra el tiempo y un eje horizontal que muestra el grupo de objetos.

Cada mensaje en un diagrama de  secuencia corresponde a uno operación en una clase, a un evento disparador, o a una transición en una máquina de estados.

2.9 Diagrama de estado

Este diagrama describe el comportamiento dinámico de los objetos, en un cierto plazo, modelando los ciclos de vida de los objetos de cada clase; tomando a cada objeto como una entidad aislada que se comunica con el resto del sistema a través de eventos. A su vez los eventos representan las clases de cambios por los que un objeto puede pasar.  

Características:

Un diagrama de estado describe el comportamiento de las clases, pero también el comportamiento dinámico de los casos de uso, de las colaboraciones, y de los métodos.

Es un gráfico de estados y de transiciones. Los diagramas de estados se unen a una clase y describe, la respuesta de una instancia de la clase a los eventos que recibe.

Los diagramas de estado son útiles para entender los mecanismos de control, tales como interfaces de usuarios o controladores de dispositivos.

Define los estados que un objeto puede tener y como los eventos afectan esos estados.

Captura el ciclo de vida de los objetos, subsistemas y sistemas.

2.8 Diagrama de casos de uso

Un caso de uso es una unidad coherente de funcionalidad, expresada  como transacción entre los actores y el sistema. El propósito de la vista de casos de uso es enumerar a los actores y los casos de uso, y demostrar que actores participan en cada caso  de uso.

Características:

La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.

La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherente, consistente promueve una imagen fácil del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.

2.7 Diagrama de actividades

Este tipo diagramas se pueden utilizar para modelar actividades de software, éste diagrama es provechoso para entender el comportamiento de alto nivel de la ejecución de un sistema, sin profundizar en los detalles internos de los mensajes.

Características:

Un diagrama de actividades puede contener bifurcaciones, así como divisiones de control en hilos concurrentes.

Un diagrama de actividad es la notación para un grafo de actividades, el cual es una forma especial de máquina de estados, prevista para modelar cómputos y flujos de trabajos.

Los diagramas de actividad soportan actividades tanto secuenciales como paralelas. La ejecución paralela se representa por medio de iconos de fork/espera, y en el caso de las actividades paralelas, no importa en qué orden sean invocadas pueden ser ejecutadas simultáneamente o una detrás de otra.

Los diagramas de actividad siempre están asociados a una clase, a una operación o a un caso de uso.

2.6 Diagrama de paquetes

Un diagrama de paquetes muestra como un sistema está dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones. 

Dado que normalmente un paquete está pensado como un directorio, los diagramas de paquetes suministran una descomposición de la jerarquía lógica de un sistema.

Características:

Se usan paquetes en un modelo de desarrollo para agrupar elementos relacionados.

Cada uno de los paquetes se pueden asignar a un individuo o a un equipo de desarrollo.

Los Paquetes están normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras sobre la mesa, los paquetes son buenos elementos de gestión.

 

2.5 Diagrama de despliegue

Los diagramas de despliegues muestran las relaciones físicas entre los componentes físicos y lógicos del sistema final (hardware y software).

Características:

Los elementos usados por este tipo de diagrama son nodos representados como un prisma , componentes representados como una caja rectangular con dos protuberancias del lado izquierdo y asociaciones.

El diagrama de despliegue, representa los artefactos del sistema como nodos, los cuales son conectados a través de caminos de comunicación para crear redes de sistemas de complejidad arbitraria.

Describe la arquitectura en tiempo de ejecución de procesadores, dispositivos y los componentes de software que ejecutan ésta arquitectura.

Describe una topología del sistema, estructura del hardware y el software que se ejecuta en cada unidad. 

2.4 Diagrama de estructura compuesta

Un diagrama de estructura compuesta es un diagrama que muestra la estructura interna de un clasificador, incluyendo sus puntos de interacción a otras partes del sistema. Esto muestra la configuración y relación de las partes que juntas realizan el comportamiento de clasificador contenido.

Los elementos de clase han sido descriptos en gran detalle en la sección en los diagramas de clase. Esta sección describe la forma en que las clases se pueden mostrar como elementos compuestos exponiendo interfaces y conteniendo puertos y partes.

Características:

Una estructura compuesta es un conjunto de elementos interconectados que colaboran en tiempo de ejecución para lograr algún propósito. Cada elemento tiene algún rol definido en la colaboración.

Ejemplo: 

2.3 Diagrama de objeto

Los diagramas de objetos modelan las instancias de elementos contenidos en los diagramas de clases. Un diagrama de objetos muestra un conjunto de objetos y sus relaciones en un momento concreto.

Características:

• Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase.

• Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase.

• Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias específicas de clases (objetos) en un momento particular del sistema.

2.2 Diagrama de componente

Un diagrama de componentes muestra dependencias entre los componentes – un componente es una unidad física de implementación con interfaces bien definidas pensada para ser utilizada como parte reemplazable del sistema  cada componente ofrece algunas interfaces y utiliza otras. Si las dependencias entre componentes se hacen a través de interfaces, los componentes se pueden sustituir por otros componentes que realicen las mismas interfaces.

Características:

* Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.

* Un diagrama de componentes se representa como un grafo de componentes software unidos por medio de relaciones de dependencia (generalmente de compilación). Puede mostrar también que un componente software contiene una interfaz, es decir, la soporta.

 * Normalmente los diagramas de componentes se utilizan para modelar código fuente, versiones ejecutables, bases de datos físicas.

2.1 Diagramas de Clases

Las clases son el centro alrededor del cual se organiza la vista de clases; otros elementos pertenecen o se unen a las clases. Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.

Características:

• Las clases se dibujan como rectángulos, mostrando el listado del nombre de la clase,  atributos y operaciones en compartimientos separados.

• Las relaciones entre clases se dibujan como las líneas que conectan rectángulos de clases y existen tres relaciones la dependencia, generalización y asociación.

• Cada representación tiene muchas entradas disponibles, cada una con un número de asiento único.

Historia UML

UML

Que es UML ? 

Es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de software orientado a objetos (OO). Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software.

UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo : no pretende definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado. Otros metodos de modelaje como OMT  o Booch sí definenprocess concretos. En UML los procesos de desarrollo son diferentes según los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicación en tiempo  real, que el proceso de desarrollo de una aplicación orientada a gestión , por poner un ejemplo.

Las diferencias son muy marcadas y afectan a todas las faces del proceso. El método del UML recomienda utilizar los procesos que otras metodologías tienen definidos.

Los inicios de UML 

A partir  del año 1994, Grady Booch (precursor de Booch '93) y Jim Rumbaugh (creador de OMT) se unen en una empresa  común, Rational Software Corporation, y comienzan a unificar sus dos métodos. Un año más tarde, en octubre de 1995, aparece UML (Unified Modeling Language) 0.8, la que se considera como la primera versión del UML. A finales de ese mismo año, Ivan Jacobson, creador de OOSE (Object Oriented Software Engineer) se añade al grupo.

Como  objetivos  principales de la consecución de un nuevo método que aunara los mejores aspectos de sus predecesores, sus protagonistas se propusieron lo siguiente:

• El método debía ser capaz de modelar no sólo sistemas de software sino otro tipo de sistemas reales de la empresas, siempre utilizando los conceptos de la orientación a objetos .
• Crear un lenguaje para modelado utilizable a la vez por maquinas y por personas.
• Establecer un acoplamiento explícito de los conceptos y los artefactos ejecutables.
• Manejar los problemas típicos de los sistemas complejos de misión critica .

Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los métodos más utilizados sigan evolucionando en conjunto y no por separado.

 Modelado de objetos

En la especificación del UML podemos comprobar que una de las partes que lo componen es un metamodelo formal. Un metamodelo es un modelo que define el lenguaje para expresar otros modelos . Un modelo en OO es una abstracción cerrada semánticamente de un sistema y un sistema es una colección de unidades conectadas que son organizadas para realizar un propósito específico.El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en términos concretos. El modelado no es más que la construcción  de un modelo a partir de una especificación.

Los modelos además, al no ser una representación que incluya todos los detalles de los originales, permiten probar más fácilmente los sistemas que modelan y determinar los errores. Según se indica en la metodologia OMT (Rumbaugh), los modelos permiten una mejor comunicación con el cliente por distintas razones:

• Es posible enseñar al cliente una posible aproximación de lo que será el producto final.
• Proporcionan una primera aproximación al problema que permite visualizar cómo quedará el resultado.
• Reducen la complejidad del original en subconjuntos que son fácilmente tratables por separado.

Artefactos para el Desarrollo de Proyectos

Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software. Pueden ser artefactos un modelo, una descrpcion o un software. Los artefactos de UML se especifican en forma de diagramas, éstos, junto con la documentación sobre el sistema constituyen los artefactos principales que el modelador puede observar.




Se necesita más de un punto de vista para llegar a representar un sistema. UML utiliza los diagramas gráficos para obtener estos distintos puntos de vista de un sistema:

• Diagramas de implementacion.
• Diagramas de comportamiento o interacción.
• Diagramas de Casos de uso.
• Diagramas de Clases.