UML
EL LENGUAJE UNIFICADO DE MODELADO (UML)
En todas las disciplinas de la Ingeniería se hace evidente la importancia de los modelos ya que describen el aspecto y la conducta de "algo". Ese "algo" puede existir, estar en un estado de desarrollo o estar, todavía, en un estado de planeación. Es en este momento cuando los diseñadores del modelo deben investigar los requerimientos del producto terminado y dichos requerimientos pueden incluir áreas tales como funcionalidad, performance y confiabilidad. Además, a menudo, el modelo es dividido en un número de vistas, cada una de las cuales describe un aspecto específico del producto o sistema en construcción.
El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de pequeño tamaño se obtienen beneficios de modelado, sin embargo es un hecho que entre más grande y más complejo es el sistema, más importante es el papel de que juega el modelado por una simple razón: "El hombre hace modelos de sistemas complejos porque no puede entenderlos en su totalidad".
UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 1.0 de UML fue liberada en Enero de 1997 y ha sido utilizado con éxito en sistemas construidos para toda clase de industrias alrededor del mundo: hospitales, bancos, comunicaciones, aeronáutica, finanzas, etc.
Los principales beneficios de UML son:
Mejores tiempos totales de desarrollo (de 50 % o más).
Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
Establecer conceptos y artefactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
Mejor soporte a la planeación y al control de proyectos.
Alta reutilización y minimización de costos.
UML, ¿Método o Lenguaje de Modelado?
UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método.
Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo ¾ los símbolos utilizados en los modelos ¾ y un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas son sintácticas, semánticas y pragmáticas
Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son:
Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los actores externos.
Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la estructura estática y la conducta dinámica del sistema.
Vista de Componentes: Muestra la organización de los componentes de código.
Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicación y sincronización que están presentes en un sistema concurrente.
Vista de Distribución: muestra la distribución del sistema en la arquitectura física con computadoras y dispositivos llamados nodos.
Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución.
Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.
Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario.
FASES DEL DESARROLLO DE UN SISTEMA
Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis, Diseño, Programación y Pruebas.
Análisis de Requerimientos
UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del modelado de casos de uso, los actores externos que tienen interés en el sistema son modelados con la funcionalidad que ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son modelados con relaciones y tienen asociaciones entre ellos o éstas son divididas en jerarquías. Los actores y casos de uso son descritos en un diagrama use-case. Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo que él (o ella) espera del sistema sin considerar la funcionalidad que se implementará. Un análisis de requerimientos puede ser realizado también para procesos de negocios, no solamente para sistemas de software.
Análisis
La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso también se consideran en esta fase a través de los modelos dinámicos en UML. Es importante notar que sólo se consideran clases que están en el dominio del problema (conceptos del mundo real) y todavía no se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.
Diseño
En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio del problema del análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase de programación.
Programación
En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a código.
Pruebas
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas por el programador. Las pruebas de integración integran componentes y clases en orden para verificar que se ejecutan como se especificó. Las pruebas de sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de aceptación conducidas por el cliente verifican que el sistema satisface los requerimientos y son similares a las pruebas de sistema.
Los diagramas de clases de UML pueden utilizarse para una gran variedad de propósitos:
· Para proporcionar una descripción de los tipos que se utilizan en un sistema y se pasan entre sus componentes que no tenga nada que ver con su implementación.
Por ejemplo, en el código .NET, el tipo Pedido de menú podría implementarse en la capa del negocio; en XML, en las interfaces entre los componentes; en SQL, en la base de datos, y en HTML, en la interfaz de usuario. Aunque estas implementaciones tengan un nivel de detalle diferente, la relación entre el tipo Pedido de menú y otros tipos, como Menú y Pago, es siempre la misma. El diagrama de clases de UML permite analizar estas relaciones con independencia de las implementaciones.
· Para clarificar el glosario de términos que se utiliza en la comunicación entre la aplicación y los usuarios y en las descripciones de las necesidades de los usuarios. Para obtener más información, vea Crear modelos de los requisitos de los usuarios.
Por ejemplo, piense en los casos de usuario, los casos de uso y otras descripciones de los requisitos de la aplicación de un restaurante. En este tipo de descripción, encontrará términos como Menú, Pedido, Comida, Precio, Pago, etc. Puede dibujar un diagrama de clases de UML en el que se definan las relaciones entre estos términos. De este modo, se reducirá el riesgo de inconsistencias en las descripciones de los requisitos, así como en la interfaz de usuario y los documentos de ayuda.
Relación con otros diagramas
Un diagrama de clases de UML normalmente se crea junto con otros diagramas de modelado para proporcionar descripciones de los tipos que utilizan. En cada caso, la representación física de los tipos no está implícita en ninguno de los diagramas.
DIAGRAMAS DE SECUENCIA
Los diagramas de secuencia pueden utilizarse para una gran variedad de propósitos y con diferentes niveles de detalle sobre el programa. Las ocasiones más frecuentes en las que se crea un diagrama de secuencia son las siguientes:
· Si tiene un diagrama de casos de uso en el que se resumen los usuarios del sistema y sus objetivos, puede dibujar diagramas de secuencia para describir el modo en que los principales componentes del sistema interactúan para lograr el objetivo de cada caso de uso. Para obtener más información, vea Diagramas de casos de uso de UML: Instrucciones.
· Si ha identificado los mensajes que llegan a una interfaz de un componente, puede crear diagramas de secuencia en los que se describa cómo interactúan los elementos internos del componente para lograr el resultado necesario para cada mensaje entrante. Para obtener más información, vea Diagramas de componentes de UML: Instrucciones.
El uso de diagramas de secuencia tiene algunas ventajas:
· Puede verse con facilidad cómo se distribuyen las tareas entre los componentes.
· Pueden identificarse los modelos de interacción que dificultan la actualización de software.
Existen varios mecanismos que permiten utilizar los diagramas de secuencia de UML junto con otros diagramas.
Líneas de vida y tipos
Las líneas de vida que se dibujan en un diagrama de secuencia pueden representar instancias típicas de los componentes o clases del sistema. Puede crear líneas de vida a partir de tipos y tipos a partir de líneas de vida y mostrar los tipos en diagramas de clases de UML y diagramas de componentes de UML. Para obtener más información, vea Clases y líneas de vida.
Tipos de parámetros
También puede describir en un diagrama de clases de UML los tipos de parámetros y valores devueltos utilizados en los mensajes enviados entre las líneas de vida.
Detalles de casos de uso
Un caso de uso representa el objetivo de un usuario, junto con una secuencia de pasos para lograr dicho objetivo. La secuencia de pasos se puede describir de varias maneras. Una opción es crear un diagrama de secuencia en el que se muestren las interacciones entre los usuarios y los principales componentes del sistema. Para obtener más información, vea Diagramas de casos de uso de UML: Instrucciones.
Código fuente
Puede generar un diagrama de secuencia desde el código fuente. Puede revisar el diagrama para probar diferentes opciones de diseño. Si lo desea, también puede copiar el contenido en un diagrama de secuencia de un proyecto de modelado. Para obtener más información, vea Generar diagramas de secuencia desde el código.
Para obtener una lista completa de los elementos de los diagramas de secuencia, vea Diagramas de secuencia UML: Referencia.
En Cómo: Modificar un modelo UML y los diagramas, se describen en detalle los pasos para crear diagramas de modelado.
|
Para crear un diagrama de secuencia
1. En el menú Arquitectura, haga clic en Nuevo diagrama.
2. En Plantillas, haga clic en Diagrama de secuencia UML.
3. Especifique un nombre para el diagrama.
4. En Agregar a proyecto de modelado, seleccione un proyecto de modelado existente de la solución o Crear un nuevo proyecto de modelado y, a continuación, haga clic en Aceptar.
Aparece un nuevo diagrama de secuencia con el cuadro de herramientas Diagrama de secuencia. El cuadro de herramientas contiene los elementos y conectores requeridos
DIAGRAMA DE CASOS DE USO
En Visual Studio Ultimate, puede dibujar un diagrama de casos de uso para resumir quién usa la aplicación o sistema y qué pueden hacer. Para crear un diagrama de casos de uso de UML, en el menú Arquitectura, haga clic en Nuevo diagrama.
Si desea una demostración en vídeo, vea Organizing Features into Use Cases.
Con la ayuda de un diagrama de casos de uso, puede analizar y notificar:
· Los escenarios en los que el sistema o aplicación interactúa con personas, organizaciones o sistemas externos.
· Los objetivos que el sistema o aplicación ayuda a conseguir.
· El ámbito del sistema.
En un diagrama de casos de uso, no se muestran los casos de uso en detalle; solamente se resumen algunas de las relaciones entre los casos de uso, los actores y los sistemas. En concreto, en el diagrama no se muestra el orden en el que se llevan a cabo los pasos para lograr los objetivos de cada caso de uso. Esos detalles pueden describirse en otros diagramas y documentos, que pueden vincularse a cada caso de uso. Para obtener más información, vea en este tema Describir los casos de uso en detalle.
En las descripciones que se proporcionen de los casos de uso se utilizarán diversos términos relacionados con el dominio en el que trabaja el sistema, como Ventas, Menú, Cliente, etc. Resulta importante definir estos términos y sus relaciones y, para ello, puede resultar útil un diagrama de clases de UML. Para obtener más información, vea Diagramas de clases de UML: Instrucciones.
Los casos de uso solamente se utilizan para los requisitos funcionales de un sistema. Otros requisitos, como las reglas de negocios, los requisitos de calidad del servicio y las restricciones de implementación, deben representarse por separado. La arquitectura y los detalles internos también deben describirse de forma independiente. Para obtener más información acerca de cómo se definen los requisitos del usuario, vea Crear modelos de los requisitos de los usuarios.
Los ejemplos que se utilizan en este tema están relacionados con un sitio web en el que los clientes pueden hacer pedidos de comida de restaurantes locales.
Diagrama de casos de uso
Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso.
Es importante resaltar que los diagramas de casos de uso no están pensados para representar el diseño y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso sirven para facilitar la comunicación con los futuros usuarios del sistema, y con el cliente, y resultan especialmente útiles para determinar las características necesarias que tendrá el sistema. En otras palabras, los diagramas de casos de uso describen qué es lo que debe hacer el sistema, pero no cómo.
Diagrama de clases
Los diagramas de clases muestran las diferentes clases que componen un sistema y cómo se relacionan unas con otras. Se dice que los diagramas de clases son diagramas «estáticos» porque muestran las clases, junto con sus métodos y atributos, así como las relaciones estáticas entre ellas: qué clases «conocen» a qué otras clases o qué clases «son parte» de otras clases, pero no muestran los métodos mediante los que se invocan entre ellas.
Diagramas de secuencia
Los diagramas de secuencia muestran el intercambio de mensajes (es decir la forma en que se invocan) en un momento dado. Los diagramas de secuencia ponen especial énfasis en el orden y el momento en que se envían los mensajes a los objetos.
En los diagramas de secuencia, los objetos están representados por líneas intermitentes verticales, con el nombre del objeto en la parte más alta. El eje de tiempo también es vertical, incrementándose hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operación y los parámetros.
Diagrama de estado
Los diagramas de estado muestran los diferentes estados de un objeto durante su vida, y los estímulos que provocan los cambios de estado en un objeto.
Los diagramas de estado ven a los objetos como máquinas de estado o autómatas finitos que pueden estar en un conjunto de estados finitos y que pueden cambiar su estado a través de un estímulo perteneciente a un conjunto finito. Por ejemplo, un objeto de tipo NetServer puede tener durante su vida uno de los siguientes estados:
· Listo
· Escuchando
· Trabajando
· Detenido
y los eventos que pueden producir que el objeto cambie de estado son
· Se crea el objeto
· El objeto recibe un mensaje de escucha
· Un cliente solicita una conexión a través de la red
· Un cliente finaliza una solicitud
· La solicitud se ejecuta y ser termina
· El objeto recibe un mensaje de detención
· etc
Diagramas de componentes
Los diagramas de componentes muestran los componentes del software (ya sea las tecnologías que lo forman como Kparts, componentes CORBA, Java Beans o simplemente secciones del sistema claramente distintas) y los artilugios de que está compuesto como los archivos de código fuente, las librerías o las tablas de una base de datos.
Los componentes pueden tener interfaces (es decir clases abstractas con operaciones) que permiten asociaciones entre componentes.
Diagramas de implementación
Los diagramas de implementación muestran las instancias existentes al ejecutarse así como sus relaciones. También se representan los nodos que identifican recursos físicos, típicamente un ordenador así como interfaces y objetos (instancias de las clases).
Diagramas de relación de entidad
Los diagramas de relaciones de entidad (diagramas ER) muestran el diseño conceptual de las aplicaciones de bases de datos. Representan varias entidades (conceptos) en el sistema de información y las relaciones y restricciones existentes entre ellas. Una extensión de los diagramas de relaciones de entidad llamado «diagramas de relaciones de entidad extendida» o «diagramas de relaciones de entidad mejoradas» (EER), se utiliza para incorporar las técnicas de diseño orientadas a objetos en los diagramas ER.
Diagramas de colaboración
Los diagramas de colaboración muestran las interacciones que ocurren entre los objetos que participan en una situación determinada. Esta es más o menos la misma información que la mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el tiempo, mientras que los diagramas de colaboración fijan el interés en las relaciones entre los objetos y su topología.
En los diagramas de colaboración los mensajes enviados de un objeto a otro se representan mediante flechas, mostrando el nombre del mensaje, los parámetros y la secuencia del mensaje. Los diagramas de colaboración están indicados para mostrar una situación o flujo programa específicos y son unos de los mejores tipos de diagramas para demostrar o explicar rápidamente un proceso dentro de la lógica del programa.
No hay comentarios:
Publicar un comentario