Unidad 2 Modelaje de lenguaje unificado (UML)

Unidad 2 Modelaje de lenguaje unificado (UML) 

2.1 Introducción

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.

Collage de diagramas UML.

2.2 Tipos de Diagramas 

• Diagramas de Estructura
• Diagramas de Comportamiento 

2.3 Diagramas de Estructura

Un diagrama de estructura es un tipo de diagrana en el Lenguaje de Modelado Unificado (UML), que muestra la estructura interna de una clase y las colaboraciones que esta estructura hace posibles. Esto puede incluir partes internas, puertas mediante las cuales, las partes interactúan con cada una de las otras o mediante las cuales, instancias de la clase interactúan con las partes y con el mundo exterior, y conectores entre partes o puertas. 

2.3.1 Diagrama de clase 

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, orientados a objetos.

• Propiedad de objetos que tienen propiedades y/u operaciones que contienen un contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de lógica de negocio, dependiendo de quién diseñe el sistema se pueden unir los datos con las operaciones.

• El diagrama de clases incluye mucha más información como la relación entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una interfaz gráfica.

• Presenta las clases del sistema con sus relaciones estructurales y de herencia.

Ejemplo de Diagrama de clase 

2.3.2 Diagrama  de Componentes

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado.

Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema

2.3.3 Diagrama de Objetos

Los diagramas de objetos son utilizados durante el proceso de Análisis y Diseño de los sistemas informáticos en la metodología UML.

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. 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.

Una diferencia con los diagramas de clase es que el compartimiento de arriba va en la forma Nombre de objeto: Nombre de clase.

Ejemplo de Diagrama de Objetos

2.3.4 Diagramas de Paquetes 

En el Lenguaje Unificado de Modelado, un diagrama de paquetes muestra cómo 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.

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. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido.

2.3.5 Diagrama de actividades

En Lenguaje Unificado de Modelado (UML), un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un diagrama de actividades muestra el flujo de control general.

Características 

Un diagrama de flujo presenta generalmente un único punto de inicio y un único punto de término, aunque puede tener más, siempre que cumpla con la lógica requerida.

Las siguientes son acciones previas a la realización del diagrama de flujo:

• Identificar las ideas principales al ser incluidas en el diagrama de flujo. Deben estar presentes el autor o responsable del proceso, los autores o responsables del proceso anterior y posterior y de otros procesos interrelacionados, así como las terceras partes interesadas.
• Definir qué se espera obtener del diagrama de flujo.
• Identificar quién lo empleará y cómo.
• Establecer el nivel de detalle requerido.
• Determinar los límites del proceso a describir.

Los pasos a seguir para construir el diagrama de flujo son:

• Establecer el alcance del proceso a describir. De esta manera quedará fijado el comienzo y el final del diagrama. Frecuentemente el comienzo es la salida del proceso previo y el final la entrada al proceso siguiente.
• Identificar y listar las principales actividades/subprocesos que están incluidos en el proceso a describir y su orden cronológico.
• Si el nivel de detalle definido incluye actividades menores, listarlas también.
• Identificar y listar los puntos de decisión.
• Construir el diagrama respetando la secuencia cronológica y asignando los correspondientes símbolos.
• Asignar un título al diagrama y verificar que esté completo y describa con exactitud el proceso elegido.

2.4 Diagramas de comportamiento 

Los diagramas de comportamiento se emplean para visualizar, especificar, construir y documentar los aspectos dinámicos de un sistema.

Los aspectos dinámicos de un sistema de software involucran cosas tales como el flujo de mensajes a lo largo del tiempo y el movimiento físico de componentes en una red. 

2.4.1 Diagrama de Caso de uso 

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado Unificado (UML), define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.

• 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 coherentes y consistentes promueven una imagen fácil de comprender del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.

2.4.2 Diagramas de Secuencia 

El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según uml . En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"

Utilidad 

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, 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 intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

2.4.3 Diagramas de Estado

Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. También ilustran qué eventos pueden cambiar el estado de los objetos de la clase. Normalmente contienen: estados y transiciones. Como los estados y las transiciones incluyen, a su vez, eventos, acciones y actividades, vamos a ver primero sus definiciones.

Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas explicativas y restricciones.

2.4.4 Diagramas de Colaboración

Un diagrama de colaboración en las versiones de UML es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de colaboración, también llamados diagramas de comunicación, muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de comunicació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.

• Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común.
• Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementación es llamada "enlace".

Un diagrama de comunicación es también un diagrama de clases que contiene roles de clasificador y roles de asociación en lugar de sólo clasificadores y asociaciones. Los roles de clasificador y los de asociación describen la configuración de los objetos y de los enlaces que pueden ocurrir cuando se ejecuta una instancia de la comunicación. Cuando se instancia una comunicación, los objetos están ligados a los roles de clasificador y los enlaces a los roles de asociación. El rol de asociación puede ser desempeñado por varios tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales del procedimiento. Los símbolos de enlace pueden llevar estereotipos para indicar enlaces temporales.

2.4.5 Diagramas de Distribución 

El  diagrama de distribución UML muestra la arquitectura física de un sistema informático. Puede representar a los equipos y a los dispositivos,  y también mostrar sus interconexiones y el software que se encontrará  en cada máquina.  

2.5 Adaptación de UML al proceso de desarrollo 

La estructura y naturaleza de los pasos en un esfuerzo de desarrollo es lo que se conoce metodología.

Método antiguo

El método en “cascada”, y establece que el análisis, diseño, codificación y distribución van uno después de otro como las actividades en un diagrama de actividades, solamente cuando se haya completado uno se podrá iniciar otro, este medoto reduce el impacto de la compresión obtenida en el proyecto.

El método reciente

La moderna ingeniria de programas tiende a la colaboración entre las fases del desarrollo. La ventaja es que conforme crece la compresión, el equipo incorpora nuevas ideas y genera un sistema mas confiable.

Proceso de desarrollo.

El equipo tiene que formarse de analistas para comunicarse con el cliente y comprender el problema, diseñadores para generar una solución, programadores para codificarla e ingenieros de sistemas para distribuirla; además de utilizar adecuadamente y asignar el tiempo necesario para cada fase.

Un equipo de desarrollo deberá:

* Asegurar que el equipo de desarrollo cuenta con una firme compresión del problema que se intenta resolver.

* Dar pie a un equipo que conste de una colección de responsabilidades.

* Fomentar la comunicación entre los miembros del equipo que ostente tales responsabilidades.

* Dar pie a la intercomunicación entre las fases del proceso de desarrollo.

* Desarrollar productos de trabajo que comuniquen el progreso al cliente, y eliminar el papeleo superfluo.

GRAPPLE

Para enfrentar este reto de varias facetas, GRAPPLE( Guias para la ingeniería de aplicaciones rapidas), es un conjunto de ideas adaptables y flexibles, da la oportunidad a un gerente de proyectos, con creatividad, de agregar sus propias ideas respecto a lo que funcionara en una organización en particular, y puede sustraer los pasos incluidos que no funcionen.