CARRERA PROFESIONAL DE COMPUTACIN E INFORMTICA

CURSO: DESARROLLO DE SISTEMAS II

UML
DOCENTE: Ing. JULIO AHUMADA FERNNDEZ 2013-I

Rational Unified Process (RUP)

Es un proceso iterativo e incremental. Dirigido por los casos de uso. Centrado en la arquitectura. Fases:
Comienzo. Definir el alcance del proyecto. Elaboracin. Plan de proyecto, especificar caractersticas, esbozar la arquitectura. Construccin. Construir el producto. Transicin. Entrega a los usuarios.

Rational Unified Process (RUP)

Hitos e Iteraciones

Rational Unified Process (RUP)

Fases, workflows e iteraciones

Rational Unified Process (RUP)

workflows y modelos

Modelo de Casos de Uso

Modelo de Anlisis

Modelo de Diseo

Modelo de Despliegue

Modelo de Implementacin

Proceso dirigido por casos de uso

Los casos de uso dirigen las iteraciones:

Creacin y validacin de la arquitectura. Definicin de los casos y procedimientos de prueba. Planificacin de las iteraciones. Creacin de la documentacin de usuario. Entrega del sistema

Sincronizacin del contenido de los distintos modelos

Proceso centrado en la arquitectura

Los modelos son el medio para visualizar, especificar, construir, generar y documentar la arquitectura del sistema. RUP prescribe el refinamiento sucesivo de la arquitectura.

UML: Lenguaje Unificado de Modelado

Similitud:
Arquitectos, edificios, planos Ing. Inf., programas, diagramas

UML
Unified Modeling Language. Ult. Versin 2.4.1 (Ago. 2011) Diagramas (ing. inf.)
Usados como esquemas y menos con informacin rigurosa (planos de arquitectos) Dos modos:
Ingeniera inversa: a partir de cdigo hacer diagramas Ingeniera directa: hacer diagramas y luego implementar

Dominio
Mundo en el que hay definido un problema

Modelo:
Abstraccin de un problema Formado por objetos

Objetivos de UML
Visualizar: UML permite expresar de una forma grfica, un sistema de forma que otro lo puede entender. Especificar: UML permite especificar cules son las caractersticas de un sistema antes de su construccin. Construir: A partir de los modelos especificados, se pueden construir los sistemas diseados. Documentar: Los propios elementos grficos sirven como documentacin del sistema desarrollado que pueden servir para su futura revisin.

Diagramas UML
Est compuesto por diversos elementos grficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo. Es importante destacar que un modelo UML describe lo que supuestamente har un sistema, pero no dice cmo implementar dicho sistema.

Diagrama de clases
Pensar en las cosas que nos rodean. Es probable que muchas de esas cosas tengan atributos (propiedades) y que realicen determinadas acciones. Podramos imaginar cada una de esas acciones como un conjunto de tareas. Encontraremos que las cosas naturalmente se agrupan en categoras (automviles, mobiliario, lavadoras ... ). A tales categoras las llamaremos clases. Una clase es una categora o grupo de cosas que tienen atributos y acciones similares. Cualquier cosa dentro de la clase Lavadoras tiene atributos como son la marca, el modelo, el nmero de serie y la capacidad. Entre las acciones de las cosas de esta clase se encuentran: "agregar ropa", "agregar detergente", iniciar lavado y "sacar ropa".

Diagrama de clases
Como ejemplo esta el caso de una Mquina Recicladora: Sistema que controla una mquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:
Registrar el nmero de tems ingresados. Imprimir un recibo cuando el usuario lo solicita:
Describe lo depositado El valor de cada item Total

El usuario/cliente presiona el botn de comienzo Existe un operador que desea saber lo siguiente:
Cuantos tems han sido retornados en el da. Al final de cada da el operador solicita un resumen de todo lo depositado en el da.

El operador debe adems poder cambiar:

Informacin asociada a temes. Dar una alarma en el caso de que:
Item se atora. No hay ms papel

Casos de Uso
Describen qu hace el sistema desde el punto de vista de un observador externo. Ponen nfasis en qu hace el sistema, no en cmo lo hace. Un escenario es una instancia particular de un diagrama de casos de uso. Ejemplo de lo que ocurre cuando alguien interacta con el sistema

Casos de Uso
Actor = Algo con comportamiento (persona, otro programa, organizacin...), que interacta con el sistema. Escenario (instancia de caso de uso) = Secuencia de acciones e interacciones entre los actores y el sistema. Caso de Uso = Coleccin de escenarios (xito y fracaso) que describen actores que usan el sistema para conseguir un objetivo.

Casos de Uso
Pasos: Identificar los lmites del sistema. Identificar los actores principales. Para cada uno, identificar sus objetivos. Definir casos de uso que satisfagan sus objetivos.

Casos de Uso: Ejemplo

CASO DE USO 1: Procesar venta (TPV) Interesados y objetivos:
Cajero: Quiere anotaciones precisas y rpidas de precios, sin errores. Cliente: Quiere que el pago sea rpido con el mnimo esfuerzo. Quiere una prueba de compra para justificar devoluciones. Compaa: Quieren almacenar las transacciones y satisfacer los intereses de los clientes. Comercial: Quiere que se le actualicen sus comisiones por venta. Agencias de impuestos gubernamentales: Quieren recolectar impuestos de cada venta. Puede que haya varias agencias (nacionales, regionales, etc.) Servicios de Autorizacin de Pagos (por tarjetas de crdito): Quiere recibir peticiones digitales de autorizaciones en el formato y protocolo correcto.

Precondiciones:
El cajero se ha identificado y autentificado.

Casos de Uso: Ejemplo

Garanta de xito (Postcondiciones):
Se registra la compra en el sistema. Se calcula el impuesto aplicable. Se actualizan los sistemas de inventario y de contabilidad. Se registran las comisiones. Se genera un recibo. Se registran las aprobaciones de pago por tarjeta.

Escenario principal de Exito:

A. Llega un clienta al TPV con bienes o servicios que comprar. B. El cajero comienza una nueva compra. C. El cajero introduce un identificador de producto. D. El sistema registra el elemento y presenta una descripcin del mismo, su precio y total actual. Se calcula el precio de una lista de reglas.
El cajero repite los pasos 3-4 hasta que no hay ms elementos.

E. El sistema presenta el total con los impuestos calculados. F. El cajero le dice el total al cliente, y le pide que pague. G. El cliente paga y el sistema procesa el pago. H. El sistema registra la venta completada y manda la informacin a los sistemas externos de inventario y contabilidad. I. El sistema genera el recibo. J. El cliente se va.

Casos de Uso: Ejemplo

Extensiones (Flujos alternativos): a*. En cualquier momento, el sistema falla. 3a. Identificador invlido.
1. El sistema seala un error y rechaza la entrada.

7a. Pago en efectivo. ... 7b. Pago con tarjeta. ...

Requisitos especiales:
Pantalla tctil en panel grande y plano. El texto debe ser visible desde un metro. Respuesta de autorizacin de crdito en menos de 30 secs, el 90% de las veces. Recuperacin robusta cuando el acceso a sistemas externos (tales como el inventario, impuestos, etc.) falla. Posibilidades de internacionalizacin de texto. Reglas de negocio insertables en los pasos 3 y 7.

Casos de Uso: Ejemplo

Lista de variaciones de tecnologa y datos: 3a. Se introduce el identificador del elemento mediante escner de cdigo de barras o mediante el teclado. 3b. Distintos esquemas de identificadores: UPC, EAN, JAN o SKU. 7a. La informacin sobre el pago con tarjeta se puede introducir mediante el teclado o lector. 7b. Se pide firma en papel. En dos aos, creemos que muchos clientes van a querer captura de firma digital. Frecuencia de ocurrencia:
Puede ser casi continua.

Temas abiertos:
Cules son las posibles variaciones en las leyes sobre impuestos? Explorar el tema de recuperacin en caso de fallo de sistemas externos. Qu modificaciones se necesitan para negocios distintos? Debe el cajero extraer el cajn con la recaudacin al terminar? Puede el 21 cliente usar directamente el lector de tarjetas o es el cajero el que lo hace?

Casos de Uso: Ejemplo

Ejemplo: Aplicacin para una Galera de Arte

Te encargan realizar una aplicacin para la compra-venta de cuadros. En cuanto a la compra de cuadros, una vez que el agente introduce unos datos bsicos sobre el cuadro, el sistema debe proporcionar el precio recomendado que el agente de la galera debera pagar. Si el vendedor del cuadro acepta la oferta, entonces el agente de la galera introduce ms detalles (sobre el vendedor del cuadro y la venta). Los datos bsicos incluyen el nombre y apellidos del artista, el ttulo y fecha de la obra, sus dimensiones, la tcnica (leo, acuarela u otras tcnicas), el tema (retrato, naturaleza muerta, paisaje, otro) y la clasificacin (obra maestra, obra representativa, otro tipo). Si es obra maestra, el precio recomendado se calcula comparando el cuadro introducido con los que hay en el registro de cuadros, tomando el ms parecido y aplicando un algoritmo que tiene en cuenta la coincidencia de tema, la tcnica y las dimensiones del cuadro. El sistema debe utilizar informacin de subasta de todo el mundo que ahora la galera recibe en un CD de manera mensual. Para una obra representativa, el precio recomendado se calcula como si fuera una obra maestra y luego se aplica una correccin. Para una obra de otro tipo, se calcula utilizando el rea del cuadro y un coeficiente de moda para el artista. Si no hay coeficiente de moda para un artista, el agente tiene por norma no comprar el cuadro. El coeficiente de moda varia de mes a mes. Si el cuadro finalmente se compra, se introducen datos adicionales. En cuanto a la venta de cuadros por parte de la galera, el sistema simplemente registra la fecha de venta, el nombre y direccin del comprador y el precio de venta real. El sistema tambin deber detectar nuevas tendencias en el mercado de arte tan pronto como sea posible. La idea es detectar secuencias de compras por valores mayores que los esperados por la obra de un artista determinado, de tal manera que tu cliente pueda comprar cuadros de ese artista antes de que otros detecten la tendencia. Con el objetivo de detectar cundo el precio de venta es mayor que el precio esperado cuando tu cliente compr el cuadro, se debe mantener un registro de todas las compras y todas las ventas. Se quieren generar tres informes: compras y ventas realizadas durante un ao, y artistas de moda.