Análisis y diseño en el desarrollo de software con UML INGENIERIA DE SOFTWARE I: UNIDAD 3 ING. RICARDO TREJO ANTECEDENTES: Origen de UML Durante la aparición de los lenguajes orientados a objetos a mediados de 1970 y hasta finales de los 1980’s, sus metodologías se enfrentaron a una creciente complejidad de aplicaciones y requirió el inicio de experimentos de enfoques alternativos para el análisis y diseño. Tales metodologías incrementaron de tan pocas como 10 hasta mas de 50 entre 1989 y 1994. Muchos usuarios de tales metodologías se enfrentaban a la dificultad de encontrar un lenguaje de modelación que cumpliera sus expectativas completamente, iniciando así una “guerra de metodologías”. Entre las metodologías posteriores que surgieron en 1994, las más sobresalientes fueron las de: • Metodología de Booch. Rational Software • OMT (Object Modeling Technique), Rumbaugh. General Electric • OOSE (Object-Oriented Software Engineering), Jacobson. Objectory En 1995, estas metodologías empezaron a compartir ideas entre si. Las metodologías de Booch y OMT (Rumbaugh) se unieron en 1995 y presentaron a la comunidad informática la metodología denominada: UNIFIED METHOD versión 0.8 Posteriormente se unió al equipo Jacobson con su método OOSE y su sobresaliente herramienta de casos de uso. La unión de este equipo, conocidos actualmente como los “Three amigos” generó prestigio en el mundo de la ingeniería de software con la construcción del nuevo lenguaje de modelación denominado: UML versión 0.9 En 1996, se estableció en consorcio de UML para lograr una definición más completa y formal. Algunos de los participantes fueron Digital Equipment Corporation, Hewlett-Packard, ILogix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments, and Unisys; resultando en la siguiente definición llamada: UML versión 1.0 En 1997, el grupo de participantes se expandió a una gran cantidad de participantes, integrando el UML con otros esfuerzos de estandarización, la versión revisada resultante: UML versión 1.1 Dicha versión fue presentada para estandarización ante la OMG (Object Management Group). Siendo aceptada y adoptada el 14 de Noviembre de 1997. Una aportación adicional más práctica fue la creación de una herramienta CASE llamada Rational Rose 98. La especificación mas actual a la fecha de UML es la versión 2.4.1 (www.omg.org/spec/UML/2.4.1). En cuanto a la herramienta CASE, Rational ROSE evolucionó a Rational Software Architect, siendo la versión actual V9.0 FUNDAMENTOS DE UML El Lenguaje Unificado de Modelado (Unified Modeling Language) UML, es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Está pensado para usarse con todos los métodos de desarrollo, etapas del ciclo de vida, dominios de aplicación y medios. UML, es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. UML, es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. UML, es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. UML, es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. UML capta la información sobre la estructura estática y el comportamiento dinámico de un sistema. El modelar un sistema desde varios puntos de vista, separados pero relacionados, permite entenderlo para diferentes propósitos. UML no es un lenguaje de programación, es un lenguaje de modelado de propósito general, para sistemas discretos, tales como los compuestos por software, firmware o lógica digital. Dentro de UML, el termino unificado, tiene los siguientes significados: Métodos históricos y notaciones: UML combina conceptos OO, notación y terminología, representando a la mayoría de los modelos existentes igual o mejor que los modelos originales. Dentro de UML, el termino unificado, tiene los siguientes significados: Métodos históricos y notaciones: Ciclo de vida de desarrollo: UML utiliza los mismos conceptos y notaciones en las diferentes etapas de desarrollo, no se requiere traducir entre etapas. Dentro de UML, el termino unificado, tiene los siguientes significados: Dominios de aplicación: UML esta pensado para trabajar igual o mejor que cualquier otro lenguaje de modelado de propósito general para la mayoría de las áreas de aplicación (Sistemas grandes, de tiempo real, distribuidos, etc..). Métodos históricos y notaciones: Ciclo de vida de desarrollo: Dentro de UML, el termino unificado, tiene los siguientes significados: Lenguajes de implementación y plataformas: UML esta pensado para ser usado en sistemas desarrollados en varios lenguajes de programación y plataformas. Dominios de aplicación Ciclo de vida de desarrollo Métodos históricos y notaciones Dentro de UML, el termino unificado, tiene los siguientes significados: Lenguajes de implementación y plataformas Dominios de aplicación Ciclo de vida de desarrollo Métodos históricos y notaciones Procesos de desarrollo: UML es un lenguaje, no una descripción de un proceso de desarrollo detallado, puede ser usado prácticamente en cualquier proceso de desarrollo existente o de nueva creación, sin embargo esta específicamente pensado para desarrollos iterativos e incrementales. Dentro de UML, el termino unificado, tiene los siguientes significados: Lenguajes de implementación y plataformas Dominios de aplicación Ciclo de vida de desarrollo Métodos históricos y notaciones Procesos de desarrollo Conceptos internos: UML ayuda a descubrir y representar las relaciones subyacentes entre varios conceptos de modelado de manera abierta y aplicable a diversas situaciones. OBJETIVOS DE UML UML es un lenguaje de modelado de propósito general para ser usado por todos los modeladores, reemplazando al menos los modelos de OMT, Booch y Objectory y otros métodos importantes, incorporando buenas practicas de diseño tales como la encapsulación, separación de temas y la captura de la intención del modelo construido. UML no pretende ser un método de desarrollo completo, no incluye un proceso de desarrollo paso a paso. Hay que tener en cuenta que UML y el proceso para usar UML son dos cosas independientes Un objetivo final de UML era ser tan simple como fuera posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesita construir. Debe ser un lenguaje universal ÁREAS CONCEPTUALES DE UML Estructura estática: Cualquier modelo debe primero definir el universo del discurso, esto es, los conceptos clave de la aplicación (clases), sus propiedades internas y las relaciones entre cada una. Comportamiento dinámico: Hay dos formas de modelar el comportamiento. Una es la historia de la vida de un objeto, que muestra la forma en que interactúa con el resto del mundo; la otra son los patrones de comunicación de un conjunto de objetos conectados que muestra como interactúan para implementar su comportamiento. Mecanismos de extensión: No importa que tan completo sea el conjunto de “facilidades” de un lenguaje, la gente querrá hacer extensiones. UML está dotado de una limitada capacidad de extensión suficiente para la mayoría de los requerimientos del “día a día” sin la necesidad de un cambio en el lenguaje básico sino solo añadiendo clases nuevas denominadas estereotipos. MODELACIÓN ¿Qué es un modelo? Es una representación, en cierto medio, de algo en el mismo u otro medio, captando los aspectos importantes de lo que estamos modelando desde cierto punto de vista, simplificando u omitiendo el resto. ¿Qué es un modelo? En un sistema de software, un modelo esta construido por un lenguaje de modelado en base a semántica y notación dentro de un contexto, adoptando varios formatos incluyendo texto y graficas. VISTAS DE UML Una vista es un subconjunto de UML que modela construcciones que representan un aspecto del sistema. La división en vistas, aunque arbitraria, es intuitiva. Área Vista Diagramas Conceptos principales Estructural Vista estática Diagrama de clases Clase, asociación, generalización, dependencia, realización, interfaz Vista de casos de uso Diagrama de casos de uso Caso de uso, actor, asociación, extensión, inclusión, generalización de casos de uso Vista de implementación / despliegue Diagrama de componentes Componente, interfaz, dependencia, realización Diagrama de despliegue Nodo, componente, dependencia, localización Dinámica Vista de maquina de estados Diagrama de estados Estado, evento, transición, acción Vista de actividad Diagrama de actividad Estado, actividad, transición de terminación, división, unión Vista de interacción Diagrama de secuencia Interacción, objeto, mensaje, activación Diagrama de colaboración Colaboración, interacción, rol de colaboración, mensaje Gestión del modelo Vista de gestión de modelo Diagrama de clases Paquete, subsistema, modelo Extensión de UML Todas Todos Restricción, estereotipo, valores etiquetados ORGANIZACIÓN DE DIAGRAMAS DE UML Diagramas UML Diagramas de estructura Diagramas de comportamiento Diagramas de interacción Diagrama de casos de uso Diagrama de estados Diagrama de clases Diagrama de componentes Diagrama de actividad Diagrama de comunicación Diagrama de tiempos Diagrama de secuencia Diagrama de despliegue Diagrama de paquetes La visualización, especificación, construcción y documentación de un sistema de software requiere que el sistema sea visto desde varias perspectivas. La arquitectura de un sistema es quizás el artefacto mas importante que puede emplearse para manejar estos puntos de vista y controlar el desarrollo iterativo e incremental de un sistema a lo largo de su ciclo de vida. La arquitectura de un sistema con gran cantidad de software puede describirse mejor a través de 5 vistas interrelacionadas. Cada vista es una proyección de la organización y la estructura del sistema, centrada en un aspecto particular de ese sistema. Esta arquitectura es conocida como “4+1 vistas” Vista de diseño Vocabulario Funcionalidad Ensamblado del sistema Gestión de configuraciones Topología del sistema Distribución Entrega Instalación Funcionamiento Capacidad de crecimiento Rendimiento Vista de implementación Vista de procesos Vista de despliegue Vista de casos de uso Comportamiento CONOCIENDO LOS REQUERIMIENTOS: Funciones del Sistema Para iniciar un modelo mediante el lenguaje UML, debemos primero identificar las funciones del sistema. Para esto debemos interpretar los requerimientos formales desde la perspectiva de la arquitectura 4+1: Caso de estudio: Terminal punto de venta Las funciones del sistema indican lo que este deberá hacer, por ejemplo autorizar los pagos a crédito. Con el objeto de verificar que algún X es de verdad una función del sistema, la siguiente oración deberá tener sentido: El sistema deberá hacer . En cambio los atributos del sistema son cualidades no funcionales, por ejemplo la facilidad de uso. El sistema deberá hacer la facilidad de uso. Los atributos del sistema no deberán formar parte del documento las especificaciones funcionales del sistema, deberán formar parte de un documento independiente. Categorías de las funciones Categoría de la función Significado Evidente Debe realizarse y el usuario debe saber que se ha realizado Oculta Debe realizarse, aunque no es visible para el usuario. Superflua Opcionales: su inclusión no repercute significativamente en el costo ni en otras funciones. Algunas funciones básicas de nuestro caso de estudio serian: # Ref Función Categoría R 1.1 Registra la venta en proceso (actual): los productos comprados. Evidente R 1.2 Calcula el total de la venta actual; se incluyen los cálculos de impuestos. Evidente R 1.3 Captura la información sobre el objeto comprado usando su código de barras mediante un lector o por captura manual. Evidente R 1.4 Reduce las cantidades de inventario al realizar una venta. Oculta R 1.5 Se registran las ventas efectuadas. Oculta R 1.6 El cajero debe introducir usuario y contraseña para utilizar el sistema Evidente R 1.7 Ofrece un mecanismo de almacenamiento persistente. Oculta R 1.8 Ofrece mecanismos de comunicación entre los procesos y entre los sistemas Oculta R 1.9 Muestra la descripción y el precio del producto registrado evidente Funciones de pago: # Ref Función Categoría R 2.1 Maneja los pagos en efectivo, capturando la cantidad ofrecida y calculando el saldo deudor. Evidente R 2.2 Maneja los pagos a crédito, capturando la información crediticia a partir de un lector de tarjetas o mediante captura manual, autorizando los pagos mediante un sistema externo. Evidente R 2.3 Maneja pagos con cheque, capturando manualmente datos de identificación oficial del cliente. Evidente R 2.4 Registra los pagos en el sistema de cuentas por cobrar, pues al cobrar con cheque el pago se registraría hasta que este sea depositado y acreditado a la cuenta de la tienda. Oculta Atributos del sistema: Atributo Detalles y restricciones de la frontera Tiempo de respuesta Cuando se registre un producto vendido, la descripción y el precio aparecerán en pantalla en no mas de 5 segundos. Metáfora de interfaz Ventanas orientadas a la metáfora de una forma y cuadros de dialogo. Maximizar una navegación fácil con teclado o pantalla táctil. Tolerancia a fallas Debe permitir la captura manual de artículos y precios al momento de la venta para evitar que el sistema falle si se registra un articulo no existente en el inventario. Plataforma de sistema operativo Microsoft Windows XP, Vista o 7 UML: DIAGRAMA DE CASOS DE USO Caso de uso: Los casos de uso se emplean para capturar el comportamiento deseado del sistema en desarrollo sin tener que especificar como se implementa ese comportamiento. Denotan solo comportamientos esenciales del sistema. Definición de actores: Un actor representa un conjunto coherente de roles que los usuarios de los casos de uso juegan al interactuar con estos. Un actor puede ser una persona, un dispositivo de hardware o incluso otro sistema. Procesar préstamo ResponsablePrestamos Nombre Actor Caso de uso Asociación Usuario Administrador Cliente ClienteRegistrado Visitante Jerarquía de actores Frontera del sistema: Un caso de uso describe la interacción con un sistema. Las fronteras ordinarias del sistema son: • La frontera hardware/software de un dispositivo o sistema de cómputo. • El departamento de una organización. • La organización entera. Caso de Uso Actor Compra productos Cajero TPDV Registra los productos Entrega el cambio Cliente Compra productos Tienda Entrega el cambio Cliente Ejemplos de tipos de fronteras: El diagrama de caso de uso se acompaña de un documento narrativo que describe la secuencia de eventos de un actor que utiliza un sistema para completar un proceso [Jacobson ’92] Formatos de los casos de uso: En la practica, los casos de uso se pueden expresar con diferentes grados de detalle y de aceptación de las decisiones concernientes al diseño. En otras palabras, un mismo caso de uso se puede escribir mediante diferentes formatos de diversos niveles de detalle. Caso de uso de alto nivel: Describe de manera clara y concisa un proceso, mediante una breve descripción. Útil en el examen inicial de requerimientos. Comprar productos Cajero Cliente Caso de uso: comprar productos Caso de uso: Comprar productos Actores: Cliente, Cajero Tipo: Primario Descripción: Un cliente llega a la caja registradora con los artículos que comprará. El cajero registra los artículos y cobra el importe. Al terminar la operación, el cliente se marcha con los productos. Caso de uso expandido : Describe el proceso más a fondo. Contiene una sección destinada al curso normal de eventos, que nos describe paso a paso el proceso. Caso de uso: Nombre del caso de uso Actores: Lista de actores, indicando quien inicia el caso de uso Propósito: Intención del caso de uso Resumen: Repetición del caso de uso de alto nivel o una síntesis similar. Tipo: 1.- Primario, secundario u opcional. 2.- Esencial o real Referencias cruzadas: Casos relacionados de uso y funciones también relacionadas del sistema. Curso normal de eventos Acción del actor: Respuesta del sistema: Acciones numeradas de los actores Descripciones numeradas de las respuestas del sistema Caso de uso: Comprar productos en efectivo Actores: Cliente (iniciador), Cajero Propósito: Capturar una venta y su pago en efectivo. Resumen: Un cliente llega a la caja registradora con los artículos que desea comprar. El cajero registra los artículos y recibe un pago en efectivo. Al terminar la operación, el cliente se marcha con los productos comprados. Tipo: Primario y esencial. Referencias cruzadas: Funciones R1.1, R1.2, R1.3, R1.7, R1.9, R2.1 Curso normal de eventos Acción del actor: Respuesta del sistema: 1.- Este caso de uso comienza cuando un cliente llega a una caja de TPDV con los productos que desea comprar. 2.- El cajero registra el identificador de cada producto. Si hay varios productos de una misma categoría, el cajero también puede introducir la cantidad. 4.- Al terminar de introducir el producto, el cajero indica a TPDV que se concluyó la captura del producto. 6.- El cajero le indica el total al cliente. 3.- Determina el precio del producto e incorpora a la transacción actual la información correspondiente. Se presentan la descripción y el precio del producto actual. 5.- Calcula y presenta el total de la venta. Curso normal de eventos (continuación) Acción del actor: Respuesta del sistema: 7.- El cliente efectúa un pago en efectivo – el “efectivo ofrecido” – posiblemente mayor que el total de la venta. 8.- El cajero registra la cantidad de efectivo recibida. 10.- El cajero deposita el efectivo recibido y extrae el cambio del pago. El cajero da al cliente el cambio y el recibo impreso. 12.- El cliente se marcha con los artículos comprados. 9.- Muestra al cliente la diferencia. Genera un recibo. 11.- Registra la venta concluida. Cursos alternos: Línea 2: Introducción de identificador invalido. Indicar error. Línea 7: El cliente no tiene suficiente dinero. Cancelar la transacción de la venta. Caso de uso primarios, secundarios y opcionales Establecen prioridades en el desarrollo mediante la clasificación: • Primarios: Representan los procesos comunes más importantes, como Comprar productos. • Secundarios: Representan los procesos menores o raros, por ejemplo Solicitud de surtir un nuevo producto. • Opcionales: Representan los procesos que no necesariamente se deben de abordar. Caso de uso esenciales y reales • Esenciales: Se expresan en una forma teórica que contiene poca tecnología y pocos detalles de implementación. • Reales: Describe concretamente el proceso a partir de su diseño concreto actual, sujeto a tecnologías especificas de entrada y salida. Grado de la aceptación del diseño de un caso de uso Caso esencial muy abstracto Caso real muy concreto Ejemplo Caso de uso: Retiro de efectivo Acción de los actores Respuesta del sistema 1.- El cliente se identifica 2.- Presenta opciones 3.- y así sucesivamente. 4.- y así sucesivamente. Esencial Acción de los actores Respuesta del sistema 1.- El cliente introduce su tarjeta 2.- Pide el numero de identificación personal (NIP) 3.- Introduce el NIP con un teclado en pantalla táctil. 4.- Muestra el menú de opciones. 5.- y así sucesivamente. 6.- y así sucesivamente. Real Sistema terminal punto de venta (procedimiento): • Identificar actores y casos de uso • Escribir casos de uso en formato de alto nivel • Dibujar un diagrama de casos de uso • Relacionar los casos de uso • Escribir algunos casos esenciales expandidos de uso • Si es necesario, escribir algunos casos reales de uso Tipos de relaciones entre casos de uso Relación Función Notación Asociación La ruta de comunicación entre un actor y el caso de uso en el que participa. Extensión La agregación de comportamiento adicional a un caso de uso base el cual es desconocido. Inclusión La agregación de comportamiento adicional a un caso de uso base que describe explícitamente la agregación Generalización Una relación entre un caso de uso general y un caso de uso más especifico que hereda y agrega atributos a el. INCLUDE: La descripción de un caso de uso grande se puede factorizar en otros casos de uso más simples. Un caso de uso puede incorporar el comportamiento de otros casos de uso como fragmentos de su propio comportamiento. No es una especialización del caso de uso original y no puede sustituirlo. EXTEND: Un caso de uso puede también definirse como una extensión incremental de un caso de uso base. Tales extensiones se incrementan a la semántica, es el caso de uso base el que es instanciado y no el caso de uso extensión. Ordenar pedido Solicitar catálogo Ordenar producto Proveer datos del cliente Fijar pago Pagar en efectivo Pagar con tarjeta Caso de uso base Caso de uso padre Casos de uso hijos Caso de uso de extensión Caso de uso de inclusión