Unidad 3 Ing Sw - Uml

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


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.


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:


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


Lenguajes de implementacin y plataformas




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.


Lenguajes de implementacin y plataformas




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


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)


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

Documents

Unidad 3 Ing Sw - Uml