Upload
spencermacias
View
52
Download
7
Embed Size (px)
Citation preview
Anlisis y diseo en el desarrollo de software con
UMLINGENIERIA DE SOFTWARE I: UNIDAD 3
ING. RICARDO TREJO
ANTECEDENTES:Origen de UML
Durante la aparicin de los lenguajes orientados a objetos a mediados de 1970 y hasta finales de los 1980s, sus metodologas se enfrentaron a una creciente complejidad de aplicaciones y requiri el inicio de experimentos de enfoques alternativos para el anlisis y diseo.
Tales metodologas incrementaron de tan pocas como 10 hasta mas de 50 entre 1989 y 1994.
Muchos usuarios de tales metodologas se enfrentaban a la dificultad de encontrar un lenguaje de modelacin que cumpliera sus expectativas completamente, iniciando as una guerra de metodologas.
Entre las metodologas posteriores que surgieron en 1994, las ms sobresalientes fueron las de:
Metodologa de Booch. Rational Software
OMT (Object Modeling Technique), Rumbaugh. General Electric
OOSE (Object-Oriented Software Engineering), Jacobson. Objectory
En 1995, estas metodologas empezaron a compartir ideas entre si.
Las metodologas de Booch y OMT (Rumbaugh) se unieron en 1995 y presentaron a la comunidad informtica la metodologa denominada:
UNIFIED METHOD versin 0.8
Posteriormente se uni al equipo Jacobson con su mtodo OOSE y su sobresaliente herramienta de casos de uso.
La unin de este equipo, conocidos actualmente como los Threeamigos gener prestigio en el mundo de la ingeniera de software con la construccin del nuevo lenguaje de modelacin denominado:
UML versin 0.9
En 1996, se estableci en consorcio de UML para lograr una definicin ms 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 definicinllamada:
UML versin 1.0
En 1997, el grupo de participantes se expandi a una gran cantidad de participantes, integrando el UML con otros esfuerzos de estandarizacin, la versin revisada resultante:
UML versin 1.1
Dicha versin fue presentada para estandarizacin ante la OMG (Object Management Group). Siendo aceptada y adoptada el 14 de Noviembre de 1997.
Una aportacin adicional ms prctica fue la creacin de una herramienta CASE llamada Rational Rose 98.
La especificacin mas actual a la fecha de UML es la versin 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 versin 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 mtodos de desarrollo, etapas del ciclo de vida, dominios de aplicacin 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 informacin sobre la estructura esttica y el comportamiento dinmico de un sistema.El modelar un sistema desde varios puntos de vista, separados pero relacionados, permite entenderlo para diferentes propsitos.
UML no es un lenguaje de programacin, es un lenguaje de modelado de propsito general, para sistemas discretos, tales como los compuestos por software, firmware o lgica digital.
Dentro de UML, el termino unificado, tiene los siguientes significados:
Mtodos histricos y notaciones: UML combina conceptos OO, notacin y terminologa, representando a la mayora de los modelos existentes igual o mejor que los modelos originales.
Dentro de UML, el termino unificado, tiene los siguientes significados:
Mtodos histricos 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 aplicacin: UML esta pensado para trabajar igual o mejor que cualquier otro lenguaje de modelado de propsito general para la mayora de las reas de aplicacin (Sistemas grandes, de tiempo real, distribuidos, etc..).
Mtodos histricos y notaciones:
Ciclo de vida de desarrollo:
Dentro de UML, el termino unificado, tiene los siguientes significados:
Lenguajes de implementacin y plataformas: UML esta pensado para ser usado en sistemas desarrollados en varios lenguajes de programacin y plataformas.
Dominios de aplicacin
Ciclo de vida de desarrollo
Mtodos histricos y notaciones
Dentro de UML, el termino unificado, tiene los siguientes significados:
Lenguajes de implementacin y plataformas
Dominios de aplicacin
Ciclo de vida de desarrollo
Mtodos histricos y notaciones
Procesos de desarrollo: UML es un lenguaje, no una descripcin de un proceso de desarrollo detallado, puede ser usado prcticamente en cualquier proceso de desarrollo existente o de nueva creacin, sin embargo esta especficamente pensado para desarrollos iterativos e incrementales.
Dentro de UML, el termino unificado, tiene los siguientes significados:
Lenguajes de implementacin y plataformas
Dominios de aplicacin
Ciclo de vida de desarrollo
Mtodos histricos 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 propsito general para ser usado por todos los modeladores, reemplazando al menos los modelos de OMT, Booch y Objectory y otros mtodos importantes, incorporando buenas practicas de diseo tales como la encapsulacin, separacin de temas y la captura de la intencin del modelo construido.
UML no pretende ser un mtodo 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 esttica: Cualquier modelo debe primero definir el universo del discurso, esto es, los conceptos clave de la aplicacin (clases), sus propiedades internas y las relaciones entre cada una.
Comportamiento dinmico: Hay dos formas de modelar el comportamiento. Una es la historia de la vida de un objeto, que muestra la forma en que interacta con el resto del mundo; la otra son los patrones de comunicacin de un conjunto de objetos conectados que muestra como interactan para implementar su comportamiento.
Mecanismos de extensin: 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 extensin suficiente para la mayora de los requerimientos del da a da sin la necesidad de un cambio en el lenguaje bsico sino solo aadiendo clases nuevas denominadas estereotipos.
MODELACIN
Qu es un modelo?
Es una representacin, 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 semntica y notacin 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 divisin en vistas, aunque arbitraria, es intuitiva.
rea Vista Diagramas Conceptos principales
Estructural Vista esttica Diagrama de clases
Clase, asociacin, generalizacin, dependencia, realizacin, interfaz
Vista de casos de uso
Diagrama de casos de uso
Caso de uso, actor, asociacin, extensin, inclusin, generalizacin de casos de uso
Vista de implementacin / despliegue
Diagrama de componentes
Componente, interfaz, dependencia, realizacin
Diagrama de despliegue
Nodo, componente, dependencia, localizacin
Dinmica Vista de maquina de estados
Diagrama de estados
Estado, evento, transicin, accin
Vista de actividad Diagrama de actividad
Estado, actividad, transicin de terminacin, divisin, unin
Vista de interaccin Diagrama de secuencia
Interaccin, objeto, mensaje, activacin
Diagrama de colaboracin
Colaboracin, interaccin, rol de colaboracin, mensaje
Gestin del modelo Vista de gestin de modelo
Diagrama de clases
Paquete, subsistema, modelo
Extensin de UML Todas Todos Restriccin, estereotipo, valores etiquetados
ORGANIZACIN DE DIAGRAMAS DE UML Diagramas
UML
Diagramas de estructura Diagramas de comportamiento
Diagramas de interaccin
Diagrama de casos de uso
Diagrama de estados
Diagrama de clases
Diagrama de componentes
Diagrama de actividad
Diagrama de comunicacin
Diagrama de tiempos
Diagrama de secuencia
Diagrama de despliegue
Diagrama de paquetes
La visualizacin, especificacin, construccin y documentacin de un sistema de software requiere que el sistema sea visto desde varias perspectivas.La arquitectura de un sistema es quizs 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 travs de 5 vistas interrelacionadas. Cada vista es una proyeccin de la organizacin y la estructura del sistema, centrada en un aspecto particular de ese sistema.
Esta arquitectura es conocida como 4+1 vistas
Vista de diseo
VocabularioFuncionalidad
Ensamblado del sistemaGestin de configuraciones
Topologa del sistemaDistribucinEntregaInstalacin
FuncionamientoCapacidad de crecimientoRendimiento
Vista de implementacin
Vista de procesosVista 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 crdito.
Con el objeto de verificar que algn X es de verdad una funcin del sistema, la siguiente oracin 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 debern formar parte del documento las especificaciones funcionales del sistema, debern formar parte de un documento independiente.
Categoras de las funciones
Categora de la funcin
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 inclusin no repercutesignificativamente en el costo ni en otras funciones.
Algunas funciones bsicas de nuestro caso de estudio serian:
# Ref Funcin Categora
R 1.1Registra la venta en proceso (actual): los productos comprados.
Evidente
R 1.2Calcula el total de la venta actual; se incluyen los clculos de impuestos.
Evidente
R 1.3Captura la informacin sobre el objeto comprado usando su cdigo 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.6El cajero debe introducir usuario y contrasea para utilizar el sistema
Evidente
R 1.7 Ofrece un mecanismo de almacenamiento persistente. Oculta
R 1.8Ofrece mecanismos de comunicacin entre los procesos y entre los sistemas
Oculta
R 1.9 Muestra la descripcin y el precio del producto registrado evidente
Funciones de pago:
# Ref Funcin Categora
R 2.1Maneja los pagos en efectivo, capturando la cantidad ofrecida y calculando el saldo deudor.
Evidente
R 2.2
Maneja los pagos a crdito, capturando la informacin crediticia a partir de un lector de tarjetas o mediante captura manual, autorizando los pagos mediante un sistema externo.
Evidente
R 2.3Maneja pagos con cheque, capturando manualmente datos de identificacin oficial del cliente.
Evidente
R 2.4Registra los pagos en el sistema de cuentas por cobrar, pues al cobrar con cheque el pago se registrara 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 descripcin y el precio aparecern en pantalla en no mas de 5 segundos.
Metfora de interfaz
Ventanas orientadas a la metfora de una forma y cuadros de dialogo.Maximizar una navegacin fcil con teclado o pantalla tctil.
Tolerancia a fallas
Debe permitir la captura manual de artculos 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.
Definicin 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 prstamo
ResponsablePrestamos
Nombre
ActorCaso de uso
Asociacin
Usuario
Administrador Cliente
ClienteRegistrado Visitante
Jerarqua de actores
Frontera del sistema:
Un caso de uso describe la interaccin con un sistema. Las fronteras ordinarias del sistema son: La frontera hardware/software de un dispositivo o sistema de
cmputo. El departamento de una organizacin. La organizacin 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 acompaa 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 aceptacin de las decisiones concernientes al diseo. 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 descripcin. 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
Descripcin: Un cliente llega a la caja registradora con los artculos que comprar. El cajero registra los artculos y cobra el importe. Al terminar la operacin, el cliente se marcha con los productos.
Caso de uso expandido :
Describe el proceso ms a fondo. Contiene una seccin 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
Propsito: Intencin del caso de uso
Resumen: Repeticin del caso de uso de alto nivel o una sntesis similar.
Tipo: 1.- Primario, secundario u opcional.2.- Esencial o real
Referenciascruzadas:
Casos relacionados de uso y funciones tambin relacionadas del sistema.
Curso normal de eventos
Accin 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
Propsito: Capturar una venta y su pago en efectivo.
Resumen: Un cliente llega a la caja registradora con los artculos que desea comprar. El cajero registra los artculos y recibe un pago en efectivo. Al terminar la operacin, 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
Accin 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 categora, el cajerotambin 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 transaccin actual la informacin correspondiente. Se presentan la descripcin y el precio del producto actual.5.- Calcula y presenta el total de la venta.
Curso normal de eventos (continuacin)
Accin del actor: Respuesta del sistema:
7.- El cliente efecta 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 artculos comprados.
9.- Muestra al cliente la diferencia. Genera un recibo.11.- Registra la venta concluida.
Cursos alternos:
Lnea 2: Introduccin de identificador invalido. Indicar error.
Lnea 7: El cliente no tiene suficiente dinero. Cancelar la transaccin de la venta.
Caso de uso primarios, secundarios y opcionales
Establecen prioridades en el desarrollo mediante la clasificacin:
Primarios: Representan los procesos comunes ms 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 terica que contiene poca tecnologa y pocos detalles de implementacin.
Reales: Describe concretamente el proceso a partir de su diseo concreto actual, sujeto a tecnologas especificas de entrada y salida.
Grado de la aceptacin del diseo de un caso de uso
Caso esencial muy abstracto
Caso real muy concreto
Ejemplo Caso de uso: Retiro de efectivo
Accin de los actores Respuesta del sistema
1.- El cliente se identifica 2.- Presenta opciones
3.- y as sucesivamente. 4.- y as sucesivamente.Esencial
Accin de los actores Respuesta del sistema
1.- El cliente introduce su tarjeta 2.- Pide el numero de identificacin personal (NIP)
3.- Introduce el NIP con un teclado en pantalla tctil.
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
Relacin Funcin Notacin
Asociacin La ruta de comunicacin entre un actor y el caso de uso en el que participa.
Extensin La agregacin de comportamiento adicional a un caso de uso base el cual es desconocido.
Inclusin La agregacin de comportamiento adicional a un caso de uso base que describe explcitamente la agregacin
Generalizacin Una relacin entre un caso de uso general y un caso de uso ms especifico que hereda y agrega atributos a el.
INCLUDE: La descripcin de un caso de uso grande se puede factorizar en otros casos de uso ms simples. Un caso de uso puede incorporar el comportamiento de otros casos de uso como fragmentos de su propio comportamiento. No es una especializacin del caso de uso original y no puede sustituirlo.
EXTEND: Un caso de uso puede tambin definirse como una extensin incremental de un caso de uso base. Tales extensiones se incrementan a la semntica, es el caso de uso base el que es instanciado y no el caso de uso extensin.
Ordenar pedido
Solicitar catlogo
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 extensin
Caso de uso de inclusin