Uml 2004 para impresion
Upcoming SlideShare
Loading in...5
×
 

Uml 2004 para impresion

on

  • 1,186 views

 

Statistics

Views

Total Views
1,186
Views on SlideShare
1,186
Embed Views
0

Actions

Likes
0
Downloads
50
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Uml 2004 para impresion Uml 2004 para impresion Presentation Transcript

    • INTRODUCCION AL UML(Lenguaje Unificado de Construcción de Modelos) .Barrera, Corroppoli, Dans, Ibañez 1 2003
    • UML• Es una herramienta que nos permitirá expresarnos en un lenguaje común• Permite facilitar la comunicación entre las distintas áreas de una organización .Barrera, Corroppoli, Dans, Ibañez 2 2003
    • Reseña históricaEl management y los paradigmas1989: el último cambio de paradigmaDel modelo piramidal al modelo en redLos tres amigos: Booch, Rumbaugh y Jacobson Tres objetivos: 1. Modelización orientada a objetos 2. Manejar distintas complejidades 3. Modelizar tanto personas como máquinasBalance entre expresividad y simplicidad .Barrera, Corroppoli, Dans, Ibañez 3 2003
    • 11/97 Se inicia el estándar OMG9/97 Distintas versiones del UML 1.1 enviado a OMG1/97 UML de los tres amigos6/96 Método unificado10/95 OMT - 2 OOSE Booch-93 Booch-91 OMT - 190-94 Técnicas orientadas a objetosLos 80Los 70 Análisis estructurado Corroppoli, Dans, Ibañez .Barrera, 4 2003
    • UML• Las cosas que usa UML (diagramas, gráficos, textos, etc) se denominan artefactos• Los conceptos (personas, viviendas, créditos, pagos, equipos, etc) se denominan objetos• Los objetos se comunican entre si a través de mensajes .Barrera, Corroppoli, Dans, Ibañez 5 2003
    • Gerente General Servicios alFinanzas Personal Producción Distribución cliente Cliente .Barrera, Corroppoli, Dans, Ibañez 6 2003
    • La organización como un proceso Cliente Interactúa con Proceso Comprende Actividades Ejecuta Unidad Organizacional Ubicada en Localización .Barrera, Corroppoli, Dans, Ibañez 7 2003
    • Sistemas de Información• Permiten: – capturar – procesar – almacenar – distribuir datos .Barrera, Corroppoli, Dans, Ibañez 8 2003
    • Un Sistema de Información• Debería servir para: Tomar decisiones. Controlar operaciones. Analizar problemas. Crear productos y servicios.Un S.I. es la respuesta a una necesidad .Barrera, Corroppoli, Dans, Ibañez 9 2003
    • ¿Qué se pretende con UML?• Disminuir la complejidad.• Que el usuario entienda la visualización.• Acortar el tiempo dedicado al diseño.• Que la visualización quede documentada.• Notación uniforme para todos los integrantes. .Barrera, Corroppoli, Dans, Ibañez 10 2003
    • Conocimiento de los requerimientos• Un proyecto no puede ser exitoso sin una especificación correcta y exhaustiva. – En esta fase se deben identificar y clasificar las funciones del Sistema – Identificar y clasificar los atributos del sistema y relacionarlos con las funciones. .Barrera, Corroppoli, Dans, Ibañez 11 2003
    • Artefactos de la fase de Requerimientos• Panorama general• Clientes• Metas• Funciones del sistema• Atributos del sistema• Grupos afectados• Suposiciones• Riesgos• Dependencias• Casos Típicos• Modelo Conceptual preliminar .Barrera, Corroppoli, Dans, Ibañez 12 2003
    • USE CASE: Caso Típico•El caso típico es una narración o caso de utilización de unsistema•Que describe la secuencia de eventos de un actor (ovarios) para completar un proceso. Sistema Caso típico Actor Actor .Barrera, Corroppoli, Dans, Ibañez 13 2003
    • Formatos de casos típicos• Según grado de detalle – Alto nivel – Expandido• Según prioridad para el desarrollo – Primarios – Secundarios – Opcionales• Según grado de abstracción – Esencial – Real .Barrera, Corroppoli, Dans, Ibañez 14 2003
    • Caso típico de alto nivel: comprar productoCaso típico: Comprar producto.Actores: Cliente, Cajero.Tipo: Primario, EsencialDescripción: Un Cliente llega a la caja con los artículos que comprará. El Cajero registra los artí- culos, cobra y devuelve el cambio. El Clien- te se va con los artículos. .Barrera, Corroppoli, Dans, Ibañez 15 2003
    • Actores• Entidad externa al sistema• Estimula al sistema con eventos• O recibe algo del sistema Cliente .Barrera, Corroppoli, Dans, Ibañez 16 2003
    • Diagrama del caso típico Caja Compra productoCajero Cliente Registra compra Entrega cambio .Barrera, Corroppoli, Dans, Ibañez 17 2003
    • Actividad• Pensar un caso típico de alto nivel – Expresarlo en forma textual o gráfica según cada uno prefiera .Barrera, Corroppoli, Dans, Ibañez 18 2003
    • Actividad• Pensemos como podríamos expandir el caso típico Comprar producto con efectivo – Hacemos un esquema donde: • A la izquierda pondremos la acción de los actores y a la derecha la respuesta del sistema • Las actividades estarán numeradas .Barrera, Corroppoli, Dans, Ibañez 19 2003
    • Ejemplo de un caso típico expandido: comprar productos con efectivo• 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 artículos. El cajero registra los productos y recibe un pago en efectivo.Al terminar la operación, el Cliente se marcha con los productos comprados • Primario y esencial• Tipo • Funciones: Las veremos más adelante• Referencias cruzadas .Barrera, Corroppoli, Dans, Ibañez 20 2003
    • Ejemplo de un caso típico expandido: comprar productos con efectivo (Cont) Curso normal de los eventos Acción del actor Respuesta del sistema1. Este caso comienza cuando un Cliente llega a una caja con productos que desea comprar2. El Cajero registra el identificador 3. Determina el precio del producto e de cada producto. incorpora a la transacción actual Si hay varios productos de una la información correspondiente. misma categoría, el Cajero Se presenta la descripción y el también puede introducir la precio del producto actual. cantidad .Barrera, Corroppoli, Dans, Ibañez 21 2003
    • Ejemplo de un caso típico expandido: comprar productos con efectivo (Cont) Acción del actor Respuesta del sistema4. Al terminar de introducir el producto, el Cajero indica a la caja que se concluyó la captura 5. Calcula y presenta el total de la del producto. venta6. El Cajero le indica el total al Cliente7. El Cliente efectúa el pago en efectivo8. El Cajero registra la cantidad de efectivo recibida 9. Muestra al Cliente la diferencia. Genera un recibo .Barrera, Corroppoli, Dans, Ibañez 22 2003
    • Ejemplo de un caso típico expandido: comprar productos con efectivo (Cont) Acción del actor Respuesta del sistema10. El Cajero deposita el efectivo recibido y extrae el cambio del pago El Cajero da al Cliente el cambio 11. Registra la venta concluida y el recibo impreso12. El Cliente se marcha con los artículos comprados Cursos alternos Línea 2: introducción de identificador inválido. Indicar error Línea 7: el cliente no tiene suficiente dinero. Cancelar la transacción de venta .Barrera, Corroppoli, Dans, Ibañez 23 2003
    • Explicación del formato expandidoLa primera sección del caso expandido es muy suscintaCaso típico Nombre del caso típicoActores Lista de actores, en la cual se indica quién inicia el caso típicoPropósito Intención del caso típicoResumen Repetición del caso típico de alto nivel o alguna síntesis similarTipo 1. Primario, secundario u opcional 2. Esencial o realReferencias Casos típicos relacionados y funcionescruzadas también relacionadas .Barrera, Corroppoli, Dans, Ibañez 24 2003
    • Explicación del formato expandido (Cont.)• Segunda sección – Curso normal de los eventos • Acciones de los actores – Acciones numeradas de los actores • Respuestas del sistema – Descripciones numeradas de las respuestas del sistema• Tercera Sección – Curso alterno de los eventos • Alternativas que pueden ocurrir en el número de línea – Descripción de excepciones .Barrera, Corroppoli, Dans, Ibañez 25 2003
    • Identificación de los casos típicos• Basado en los actores 1. Identificar los actores 2. Para cada actor identificar los procesos que inicia o en los que participa Basado en eventos 1. Identificación de los eventos externos 2. Relacionar los eventos con los actores y con los casos típicos .Barrera, Corroppoli, Dans, Ibañez 26 2003
    • Actividad• Definamos los casos tipicos del Video Club o Biblioteca – En formato de alto nivel .Barrera, Corroppoli, Dans, Ibañez 27 2003
    • Requerimientos - Funciones del Sistema• Lo que éste debe hacer• Categorías – Evidente – Oculta – Superflua .Barrera, Corroppoli, Dans, Ibañez 28 2003
    • Funciones del sistemaRef. Función CategoríaR1.1 Registrar la venta Evidente en procesoR1.2 Descontar del Oculta stock las cantidades vendidasR1.3. Sonar un Bip por Superflua time out .Barrera, Corroppoli, Dans, Ibañez 29 2003
    • Actividad• Enumeremos las funciones que le pedimos al Sistema de Información del ejemplo – Tendremos en cuenta la descripción de los casos típicos – Incluiremos la categoría .Barrera, Corroppoli, Dans, Ibañez 30 2003
    • Requerimientos - Atributos del sistema• Son sus características – Por ejemplo: • Facilidad de uso • Tiempo de respuesta • Recuperación de datos frente a cortes .Barrera, Corroppoli, Dans, Ibañez 31 2003
    • Atributos del sistemaAtributo DescripciónTiempo de Cuando se registre un producto vendido, larespuesta descripción y el precio aparecerán en cinco segundosMetáfora de Ventanas orientadas a la metáfora de una forma yinterfaz cuadros de dialogo.Tolerancia a Debe registrar los pagos a crédito autorizados que sefallas hagan a las cuentas por cobrar en un plazo de 24 horas. .Barrera, Corroppoli, Dans, Ibañez 32 2003
    • Actividad• Enumeremos atributos que deseamos para nuestro sistema .Barrera, Corroppoli, Dans, Ibañez 33 2003
    • Atributos del sistema en las especificaciones de funciones Detalles yRef. Función Categoría Atributo Categoría restriccio-nesR1.1 Mostrar la descripción Evidente Tiempo de 5 segundos obligatorio y el precio del respuesta como máximo producto registrado Metáfora de Pantallas Obligatorio interfaz basadas en formas colorido Opcional .Barrera, Corroppoli, Dans, Ibañez 34 2003
    • Actividad• Agregaremos a las funciones ya definidas los atributos que correspondan .Barrera, Corroppoli, Dans, Ibañez 35 2003
    • Ámbito de UML la orientación a objetos• Los objetos son los conceptos, de los que hablábamos anteriormente. Atributos nombre Objeto persona edad empresa Comportamientos CambiarEdad CambiarEmpresa .Barrera, Corroppoli, Dans, Ibañez 36 2003
    • Noción de Clase e Instancia• Todos los objetos con las mismas propiedades (atributos y comportamientos) se reúnen en una familia• Esta familia son la clase y los objetos que incluyen son las instancias .Barrera, Corroppoli, Dans, Ibañez 37 2003
    • La clase Persona y sus instancias Instancia de persona nº 1 -nombre = SALAS -edad=35 Atributos -empresa=IPV nombre Instanciación edad empresa Instanciación Comportamientos Instancia de persona nº 1 CambiarEdad -nombre = FUNES -edad=55 CambiarEmpresa -empresa=VPI .Barrera, Corroppoli, Dans, Ibañez 38 2003
    • Mensajes y métodos• Los objetos no son conjunto de datos pasivos• Pueden interactuar entre sí• Se comunican entre sí a través de mensajes• Cada objeto que recibe un mensaje lo atiende con un método• El conjunto de mensajes que cada objeto puede atender se denomina interfase. .Barrera, Corroppoli, Dans, Ibañez 39 2003
    • Jerarquía de Clases y herencia• El mecanismo de la herencia permite definir nuevas clases a partir de clases existentes Persona Nombre edad empresa CambiarEdad Instancia de persona nº 1 CambiarEmpresa -nombre = RODRIGUEZ Instancia -edad=36 Asalariado -empresa=MUNI -jefe=SANENZ jefe -función=encargado sección función CambiarJefe .Barrera, Corroppoli, Dans, Ibañez 40 CambiarFunción 2003
    • Polimorfismo• El polimorfismo es una característica de la OO (orientación a objetos) que permite redefinir un comportamiento (método) heredado por una superclase .Barrera, Corroppoli, Dans, Ibañez 41 2003
    • Glosario o Diccionario de TérminosEs un documento donde se definen términos.Define aquello que requiere explicación para mejorarlas comunicaciones y evitar los malentendidos.Se crea al inicio del proyecto y va creciendo durantetoda su vida. Término Categoría Comentarios .Barrera, Corroppoli, Dans, Ibañez 42 2003
    • Ejemplos de GlosarioTérmino Categoría ComentariosComprar Productos Caso típico proceso de compra de un cliente en el localIniciar Caja Caso típico Proceso de inicialización de la cajaVenta.total:Cantidad Atributo Importe total de la venta .Barrera, Corroppoli, Dans, Ibañez 43 2003
    • Requerimientos - Atributos del Sistema• Son sus características – Por ejemplo: • Facilidad de uso • Tiempo de respuesta • etc .Barrera, Corroppoli, Dans, Ibañez 44 2003
    • Ejemplo de AtributosAtributo DescripciónTiempo de Cuando se registre un producto vendido, larespuesta descripción y el precio aparecerán en cinco segundosMetáfora de Pantallas con el isotipo del IPV, todas con elinterfaz mismo tono de fondo y las casillas distribui-das de la misma forma.Tolerancia a Debe registrar los pagos a crédito autorizadosfallas que se hagan a las cuentas por cobrar en un plazo de 24 horas. .Barrera, Corroppoli, Dans, Ibañez 45 2003
    • Actividad• Enumeremos atributos que deseamos para nuestro nuevo Sistema de Información. .Barrera, Corroppoli, Dans, Ibañez 46 2003
    • Atributos del sistema en las especificaciones de funciones Categoría Detalles y Categoría deRef. Función Atributo de función restriccio-nes atributoR1.1 Mostrar la descripción Evidente Tiempo de 5 segundos obligatorio y el precio del producto respuesta como máximo registrado Metáfora de Pantallas Obligatorio interfaz basadas en formas colorido opcional .Barrera, Corroppoli, Dans, Ibañez 47 2003
    • Actividad• Agregaremos a las funciones ya definidas los atributos que deseamos. .Barrera, Corroppoli, Dans, Ibañez 48 2003
    • UML: la Orientación a ObjetosUn objeto es un concepto (personas, cosas, hechos, ideas, etc) Nombre Atributos Comportamientos .Barrera, Corroppoli, Dans, Ibañez 49 2003
    • Atributo y comportamiento• Atributo: son las características o cualidades del objeto (también se denominan propiedades)• Comportamiento: son las acciones, aquello que el objeto sabe o puede hacer .Barrera, Corroppoli, Dans, Ibañez 50 2003
    • Ejemplo de Objeto Persona nombre edad empresaObjeto persona CambiarEdad CambiarEmpresa .Barrera, Corroppoli, Dans, Ibañez 51 2003
    • Noción de Clase e Instancia• Todos los objetos naturalmente se agrupan en categorías (clases)• Los objetos que están comprendidos dentro de las clases se denominan instancias Clase Instancia Instancia Instancia .Barrera, Corroppoli, Dans, Ibañez 52 2003
    • Actividades:1. Identifique una clase que agrupe todos estos objetos2. Agrupe diversos objetos en distintas clases. .Barrera, Corroppoli, Dans, Ibañez 53 2003
    • InstanciasPersona Instancia persona nº 1 -nombre = SALAS nombre -edad=35 edad -empresa=IPV empresa InstanciaciónCambiarEdad Instancia persona nº 2 -nombre = FUNESCambiarEmpresa -edad=55 -empresa=VPI .Barrera, Corroppoli, Dans, Ibañez 54 2003
    • Jerarquía de Clases y herencia• El mecanismo de la herencia permite definir nuevas clases a partir de clases existentes Persona Nombre edad empresa CambiarEdad CambiarEmpresa Instancia de persona nº 1 -nombre = RODRIGUEZ Asalariado Instancia -edad=36 -empresa=MUNI jefe -jefe=SANENZ función -función=encargado sección CambiarJefe CambiarFunción .Barrera, Corroppoli, Dans, Ibañez 55 2003
    • Polimorfismo• El polimorfismo es una característica de la OO (orientación a objetos) que permite redefinir un comportamiento (método) heredado por una superclase .Barrera, Corroppoli, Dans, Ibañez 56 2003
    • PolimorfismoEl polimorfismo permite usar los mismos términosdel cliente. Abrir ... .Barrera, Corroppoli, Dans, Ibañez 57 2003
    • Encapsulamiento e Interfaces Pantalla- ¿Cómo funciona?- ¡A quién le importa! Teclado .Barrera, Corroppoli, Dans, Ibañez 58 2003
    • Modelo Conceptual• Identifica los objetos.• Representa cosas del mundo real.• Es un diagrama estático donde no se define ninguna operación (proceso).• Ayuda a esclarecer la terminología. Es el artefacto más importante en la etapa del análisis del problema. .Barrera, Corroppoli, Dans, Ibañez 59 2003
    • Modelo Conceptual• Nos muestra: – Clases – Asociaciones entre esas Clases – Atributos de dichas Clases .Barrera, Corroppoli, Dans, Ibañez 60 2003
    • EjemploLínea Aérea Emplea Persona Asignada-a Asignado-a Vuelo Avión nombre edad empresa .Barrera, Corroppoli, Dans, Ibañez 61 2003
    • Maneras de definir Clases Venta Por el Símbolo Fecha hora “Una venta representa el evento de una Definición intensiva transacción de compra. Tiene fecha y hora”Venta-1Venta-2 Definición extensiva Venta-3Venta-4 .Barrera, Corroppoli, Dans, Ibañez 62 2003
    • La asignación de nombres• Se puede aplicar la metodología del cartógrafo: – Utilizar los nombres existentes en el territorio. – Excluir las características irrelevantes. – No agregar cosas que no existan. .Barrera, Corroppoli, Dans, Ibañez 63 2003
    • Descomposición del problema• Ante los problemas complejos – “divide y vencerás”• Dividimos el problema en partes comprensibles• Conviene llevarla a cabo a partir de las clases .Barrera, Corroppoli, Dans, Ibañez 64 2003
    • Descomposición del problema (cont.)• Una guía para esta fase: – Identificar varias clases – Documentar los resultados en un modelo conceptual .Barrera, Corroppoli, Dans, Ibañez 65 2003
    • Clases del Caso de la Caja Local Caja VentaAgreguemos otras clases que puedanidentificar: .Barrera, Corroppoli, Dans, Ibañez 66 2003
    • Estrategias para identificar las clases• A partir de una lista de categorías de clases• Identificación de frases nominales .Barrera, Corroppoli, Dans, Ibañez 67 2003
    • Identificación de frases nominales Acción del actor Respuesta del sistema1. Este caso comienza cuando un Cliente llega a una caja con productos que desea comprar 3. Determina el precio del2. El Cajero registra el producto e incorpora a la identificador de cada transacción actual la producto. información Si hay varios productos de correspondiente. una misma categoría, el Se presenta la descripción Cajero también puede y el precio del producto introducir la cantidad actual. .Barrera, Corroppoli, Dans, Ibañez 68 2003
    • Aplicación• Usando la lista de categorías de clases y análisis de frases nominales, construyamos una lista de clases de una aplicación del Video Club o la Biblioteca. .Barrera, Corroppoli, Dans, Ibañez 69 2003
    • Identificando las clasesA veces confundimos clases y atributos.Si consideramos algo como atributo (que no es unnúmero o texto en el mundo real), probablemente éstesea un objeto y no un atributo. Vuelo Vuelo Aeropuerto ¿o...? Destino nombre En caso de duda, convertir el atributo en clase. .Barrera, Corroppoli, Dans, Ibañez 70 2003
    • ResumiendoClase “es una descripción de un conjunto de objetos que comparten los mismos atributos, relaciones y comportamientos” .Barrera, Corroppoli, Dans, Ibañez 71 2003
    • En UML las asociaciones son relaciones entre las clases Producto Almacenado en Local 1 1 .Barrera, Corroppoli, Dans, Ibañez 72 2003
    • Asociaciones• La asociación es una relación entre dos clases que indica alguna conexión significativa e interesante entre ellas asociación Registra Caja Venta actual .Barrera, Corroppoli, Dans, Ibañez 73 2003
    • Notación de las asociaciones en UML navegabilidad nombre Vuelo Asignado-a Avión * 1 multiplicidad .Barrera, Corroppoli, Dans, Ibañez 74 2003
    • Notación de las asociaciones en UML (Ejemplo) navegabilidad nombre Asignado-a ¿ ? Adjudicatario * 1 multiplicidad .Barrera, Corroppoli, Dans, Ibañez 75 2003
    • Asociaciones prioritarias1. A es una parte lógica de B (artículo-ley)2. A es una parte física de B (habitación-casa)3. A está físicamente contenido en B (producto- estante)4. A está lógicamente contenido en B (capítulo-ley)5. A está registrado en B (ladrón-cárcel) .Barrera, Corroppoli, Dans, Ibañez 76 2003
    • Actividad• Cajero-Local • Caja-Local• Piloto-Avión • Ala-Avión• Departamento-Tienda • VentasLineadeProducto-Venta• Mantenimiento-Línea Aérea • TramodeVuelo-RutadeVuelo• Cajero-Caja • Caja-Local, Producto-Estante,• Cliente-Cajero• AgentedeReservaciones-Pasajero • Pasajero-Avión• Pago-Venta • DescripcióndeProducto-Catálogo• Pasajero-Boleto • Vuelo-ProgramadeVuelos• Reservación-Cancelación • DescripcióndeProducto-Producto• Caja-Caja • DescripcióndeVuelo-Vuelo• Ciudad-Ciudad• Avión-Línea Aérea • VentasLíneadeProducto-Venta• Venta-Caja • TrabajodeMantenimiento-Mantenimiento .Barrera, Corroppoli, Dans, Ibañez 77 2003
    • Multiplicidad• Define cuantas instancias de una clase pueden asociarse a tantas instancias de otra clase * cero o más; “muchos” 1...* uno o más 1...40 de uno a cuarenta 5 exactamente 5 2, 5, 7 exactamente dos, cinco o siete .Barrera, Corroppoli, Dans, Ibañez 78 2003
    • Las Relaciones Inolvidables• Caja Captura Venta • Para conocer la venta actual genera un total, e imprime un ticket.• Venta pagada en • Para saber si se pagó la venta,efectivo relaciona la cantidad ofrecida con el total de la venta e imprime un ticket. • Para recuperar una• ListadeProductos EspecificacióndeProducto,registra mediante un código universal deEspecificacióndePro- producto.ductos .Barrera, Corroppoli, Dans, Ibañez 79 2003
    • Atributos• Es una característica importante de un objeto.• Por ejemplo, un ticket de venta requiere la fecha y la hora.• En consecuencia la clase Venta requiere los atributos fecha y hora .Barrera, Corroppoli, Dans, Ibañez 80 2003
    • Atributos comunes •fecha •número •texto •hora •booleano •dirección •color •geometría •número de teléfono •CUIT/CUIL •código de producto •código postal •tipos enumerados .Barrera, Corroppoli, Dans, Ibañez 81 2003
    • Notación de los atributos en UML Venta Aeropuerto fecha nombre hora atributos .Barrera, Corroppoli, Dans, Ibañez 82 2003
    • AplicaciónArmemos un Modelo ConceptualTomemos como ejemplo el Video Clubo la Biblioteca .Barrera, Corroppoli, Dans, Ibañez 83 2003
    • Modelo conceptual Ventas Producto Registra_venta_de LineadeProductos 0..1 1 * cantidad Almacenado_en 1..* 1Contenida en 1 Local Venta Dirección Fecha nombre hora 1 1 1 Aloja Pagada-por 1 1..* Pago Caja Capturada-en monto .Barrera, Corroppoli, Dans, Ibañez 1 84 2003
    • Comportamiento de los sistemas - Diagramas de secuencia• Muestran gráficamente los eventos que los actores solicitan al sistema. Sistema .Barrera, Corroppoli, Dans, Ibañez 85 2003
    • • Se refiere a la secuencia normal de Ejemplo los eventos en el caso típico comprar productos sistema como caja negra actor Cajero SistemaRepetir hasta que nohaya mas productos introducirProducto(CUP, cantidad) terminarVenta() Texto que efecturaPago(monto) aclara: control, lógica, Evento del sistema iteración,etc .Barrera, Corroppoli, Dans, Ibañez 86 Inicia una operación 2003 del sistema
    • Diagrama de Secuencia Inicial• Durante la interacción un actor genera eventos dirigidos a un sistema, solicitando alguna operación a cambio• Su creación depende de la formulación previa de los casos típicos.• Es una descripción de lo que hace, sin explicar cómo lo hace.• Consideramos al sistema como una caja negra. .Barrera, Corroppoli, Dans, Ibañez 87 2003
    • Diagrama de Secuencia Inicial• Los eventos del sistema pueden incluir parámetros.• Los parámetros son los datos que acompañan la solicitud del actor.• En la aplicación de la caja del supermercado el actor “Cajero” inicia los siguientes eventos: – introducirProducto – terminarVenta – efectuarPago .Barrera, Corroppoli, Dans, Ibañez 88 2003
    • Diagrama de Secuencia Inicial• El tiempo avanza hacia abajo• El ordenamiento de los eventos debería seguir el orden indicado en el caso típico.• De no ser así deberá reverse el caso típico. .Barrera, Corroppoli, Dans, Ibañez 89 2003
    • Eventos y operaciones• El evento de un sistema: – Es un hecho externo de entrada que un actor produce en un sistema. – Como respuesta se originará una operación del sistema• La operación de un sistema – Es una acción que este ejecuta en respuesta a un evento del sistema• El nombre del evento y la operación del sistema son idénticos – La diferencia es que uno es el estímulo y el otro la respuesta .Barrera, Corroppoli, Dans, Ibañez 90 2003
    • Cómo elaborar un diagrama de secuenciaPara describir la secuencia de eventos de un caso típico:• Trace una línea que represente al sistema como una caja negra• Identifique a los actores que operan directamente sobre el sistema. Trace una línea para cada uno de ellos• A partir del caso típico identifique los eventos externos al sistema que son generados por los actores. Muéstrelos gráficamente en le diagrama.• A la izquierda del diagrama puede incluir o no el texto del caso típico .Barrera, Corroppoli, Dans, Ibañez 91 2003
    • Asignación de nombres a los eventos• Deberían reflejar el propósito• Mejora la claridad si comienza con un verbo (agregar..., introducir..., terminar..., efectuar...) .Barrera, Corroppoli, Dans, Ibañez 92 2003
    • Diagrama de secuencia del caso típico comprar productos Cajero SistemaRepetir hasta que no introducirProducto(CUP, cantidad)haya mas productos terminarVenta() efecturaPago(monto) .Barrera, Corroppoli, Dans, Ibañez 93 2003
    • Actividad• Confeccionar los diagramas de secuencia para los casos típicos primarios del Video Club o la Biblioteca. .Barrera, Corroppoli, Dans, Ibañez 94 2003
    • Contratos• Es un documento que describe lo que una operación de sistema se propone hacer.• Se escribe en forma declarativa, qué sucederá y no cómo se conseguirá. .Barrera, Corroppoli, Dans, Ibañez 95 2003
    • Contratos Caso Típico: Comprar Productos - Curso Normal de los Eventos 1 Este caso típico comienza... Cajero Sistema IntroducirProducto (cup, cantidad) terminarVenta ( ) efectuarPago (monto) Sistema terminarVenta() introducirProducto() efectuarPago()Operación: IntroducirProducto. Se trata de una nueva venta, por lo tanto despuésde esta operación fue creada una Venta... .Barrera, Corroppoli, Dans, Ibañez 96 2003
    • Secciones del ContratoNombre: Nombre de la operación y parámetros.Responsabilidades: Descripción informal de lasresponsabilidades que debe cumplir la operación.Caso: Nombre del Caso TípicoReferencias: Nº de referencia de las funciones delsistema, casos típicos, etc.Notas: notas de diseño, algoritmos, e informaciónafín.Excepciones: Casos excepcionales. .Barrera, Corroppoli, Dans, Ibañez 97 2003
    • Secciones del Contrato (cont.)Salida: Aquello que se espera recibir del sistema(objetivo del contrato).Precondiciones: Suposiciones acerca del estado delsistema antes de ejecutar la operación.Poscondiciones: El estado del sistema después de laoperación. .Barrera, Corroppoli, Dans, Ibañez 98 2003
    • Notas• Declaraciones de diseño referentes a la operación.Ejemplo: la explicación de un algoritmo para manejar la operación (fórmula para calcular la cuota de un préstamo). .Barrera, Corroppoli, Dans, Ibañez 99 2003
    • Precondiciones• Definen la suposición sobre el estado del sistema al iniciarse la operación.• Para describir las precondiciones tener en cuenta lo siguiente: • Cosas que son importantes probar en el software en algún momento de la ejecución de la operación. • Cosas de las cuales depende el éxito de la operación. .Barrera, Corroppoli, Dans, Ibañez 100 2003
    • Poscondiciones• Indican cómo cambió el sistema después de una operación.• Mejora la claridad si se redacta en pretérito ( fue creada....).• Describe los cambios necesarios para que el sistema funcione sin necesidad de describir cómo se logran.• Nos concentramos en el qué debe suceder, no la manera de conseguirlo. .Barrera, Corroppoli, Dans, Ibañez 101 2003
    • Poscondiciones• Para describir las poscondiciones utilizar las siguientes categorías: • Creación y eliminación de las instancias. • Modificación de los atributos. • Asociaciones formadas y canceladas. .Barrera, Corroppoli, Dans, Ibañez 102 2003
    • Contratos para el caso típico comprar productos Contrato para IntroducirProductos• Nombre: IntroducirProducto (CUP, cantidad).• Responsabilidades: Introducir (registrar) la venta de un producto y agregarlo a la venta. Desplegar la descripción del producto y su precio.• Tipo: Sistema.• Referencias cruzadas: Funciones del sistema R.1.1,R1.3, R1.9 Caso típico Compara productos.• Notas: Utilice el acceso super rápido a la base de datos.• Excepciones: Si el CUP no es válido, indique que se cometió un error.• Salida:• Precondiciones: .Barrera, Corroppoli, Dans, Ibañez CUP. El sistema conoce el 103 2003
    • Contratos para el caso típico comprar productos Contrato para IntroducirProductos (Cont.)• Poscondiciones: – Si se trata de una nueva venta, una Venta fue creada (creación de instancia). – Si se trata de una nueva venta, la nueva Venta fue asociada a la Caja (asociación formada). – Se creó una instancia VentaLineadeProducto a la Venta (creación de instancia). – Se asoció VentasLineadeProducto a la Venta (asociación formada). – Se estableció VentasLineadeProducto.cantidad con el valor cantidad (modificación de atributo). – La instancia VentasLineadeProducto fue asociada a una EspecificaciondeProducto, basado esto en la correspondencia del CUP (asociación formada) .Barrera, Corroppoli, Dans, Ibañez 104 2003
    • Contratos para el caso típico comprar productos Contrato para TerminarVenta• Nombre: TerminarVenta• Responsabilidades: Registrar que es el final de la captura de los productos de la venta y desplegar el total de la venta.• Tipo: Sistema.• Referencias cruzadas: Funciones del sistema R.1.2 Caso típico Compra productos.• Notas: Si no se está realizando una venta indicar que se cometió un error.• Excepciones: Si el CUP no es válido, indique que se cometió un error.• Salida:• Precondiciones: El sistema conoce el CUP. .Barrera, Corroppoli, Dans, Ibañez 105 2003
    • Contratos para el caso típico comprar productos Contrato para TerminarVenta (Cont.)• Poscondiciones: – Estableció Venta.EstaTerminada como verdadero (modificación de atributo) .Barrera, Corroppoli, Dans, Ibañez 106 2003
    • Contratos para el caso típico comprar productos Contrato para EfectuarPago• Nombre: EfectuarPago (monto)• Responsabilidades: Registrar el pago, calcular el saldo e imprimir el recibo.• Tipo: Sistema.• Referencias cruzadas: Funciones del sistema R.2.1 Caso típico Compra productos.• Notas:• Excepciones: Si la venta no está concluida, indique que se cometió un error.• Salida: Ticket• Precondiciones: .Barrera, Corroppoli, Dans, Ibañez 107 2003
    • Contratos para el caso típico comprar productos Contrato para EfectuarPago (Cont.)• Poscondiciones: – Se creó un Pago (creación de instancia). – Se asignó a Pago.MontoOfrecido el valor de monto (modificación de atributo). – Se asoció el Pago a la Venta (asociación formada). – Se asoció la Venta a la Caja para agregarla al registro histórico de las ventas terminadas (asociación formada) .Barrera, Corroppoli, Dans, Ibañez 108 2003
    • Cómo preparar un contrato• Identificar las operaciones del sistema a partir de los diagramas de secuencias.• Elaborar un contrato en cada operación del sistema.• Comenzar redactando la sección responsabilidades, describiendo el propósito de la operación. .Barrera, Corroppoli, Dans, Ibañez 109 2003
    • Cómo preparar un contrato (cont.) • Completar la sección poscondiciones describiendo los cambios de estado de los objetos en el modelo conceptual. • Para describir las poscondiciones utilizar las siguientes categorías. • Creación y eliminación de las instancias. • Modificación de los atributos. • Asociaciones formadas y canceladas. .Barrera, Corroppoli, Dans, Ibañez 110 2003
    • Actividad• Confeccionar los principales items de las operaciones del sistema referentes a los diagramas de secuencia del video. .Barrera, Corroppoli, Dans, Ibañez 111 2003
    • Conclusión de la fase de análisis Artefactos del análisis Preguntas que se contestanCasos típicos ¿Cuáles son los procesos de la aplicación?Modelo conceptual ¿Cuáles son los conceptos los términos? ¿Cuáles son los eventos y las operaciones delDiagramas de secuencia sistema?Contratos ¿Qué hacen las operaciones del sistema? .Barrera, Corroppoli, Dans, Ibañez 112 2003
    • Modelo Conceptual Diagramas deCasos Típicos casos típicos Diagramas Modelo de clase Conceptual GlosarioDiagramas Diagramasde estado de interacción .Barrera, Corroppoli, Dans, Ibañez 113 2003
    • Mensajes y métodos• Los objetos no son conjuntos de datos pasivos• Pueden interactuar entre sí• Se comunican a través de mensajes• Cada objeto que recibe un mensaje lo atiende con un método (comportamiento)• El conjunto de mensajes que cada objeto puede atender se denomina interface. .Barrera, Corroppoli, Dans, Ibañez 114 2003
    • Actividades del SistemaDiagramas de Actividad: - Diagrama de secuencia: basado en el tiempo formato en progresión vertical - Diagrama de colaboración: basado en el espacio formato en red .Barrera, Corroppoli, Dans, Ibañez 115 2003
    • Diagrama de colaboración1. Hacer un diagrama por cada operación2. Si es muy complejo, subdividir en más simples3. Empezar desde las responsabilidades4. Tener en cuenta las postcondiciones5. Considerar la descripción del caso típico .Barrera, Corroppoli, Dans, Ibañez 116 2003
    • Diagrama de colaboración teclea 1:notificar(teclea) GUI6:respuesta S. Operativo 3:actualizar(teclea)Monitor 2:actualizar(teclea) 5:mostrar(teclea) CPU 4:notificar(teclea) Tarjeta Video .Barrera, Corroppoli, Dans, Ibañez 117 2003
    • Diagrama de colaboración Sintaxis de los mensajes:Retorno : mensaje(parámetro : tipoParámetro) : tipoRetorno Mensajes a sí mismo ( o a “esto”): Mens1() Objeto 1:actualizar() Iteración: Se agrega un asterisco (*) al número de secuencia .Barrera, Corroppoli, Dans, Ibañez 118 2003
    • Diagrama de colaboraciónMensajes condicionales:mens1() 1a: [prueba mens2() Objeto1 Objeto2 1b: [no prueba mens4() 1a.1: mens3() 1b.1: mens5() Objeto4 Objeto3 .Barrera, Corroppoli, Dans, Ibañez 119 2003
    • Diagrama de colaboraciónMultiobjetos (conjunto de instancias):mens1() 1a: mens2() Objeto1 Objeto2El mensaje dirigido a un multiobjeto no setransmite a todos los elementos .Barrera, Corroppoli, Dans, Ibañez 120 2003
    • Diagrama de colaboración IntroducirProducto 1:[nueva venta] crear()introducirProducto(cup, cant) 3:hacerLineadeProducto(especif,cant) :Venta :Caja 1:1 crear()2:especif:=especificacion(cup) 3:1 crear(especif,cant) Vli:Ventas- :CatalogodeProductos LineadeProducto2:1especif:=encontrar(cup) 3.2 agregar(vli) :Especificación- :VentasLinea- deProducto Corroppoli, Dans, Ibañez .Barrera, deProducto 121 2003
    • Venta Cajafechahora terminarVenta()estaTerminadaseTermina() introducirProduc to()hacerLineadeProducto() efectuarPago()efectuarPago()Total() .Barrera, Corroppoli, Dans, Ibañez 122 2003
    • Diagrama de secuenciaObjeto 1 Objeto 2 Objeto 3 Mensaje asincrónico Activación Mensaje sincrónico Mensaje sin respuesta “crear” “temporario” Objeto 4 Mensaje simple “destruir” X .Barrera, Corroppoli, Dans, Ibañez 123 2003
    • Diagrama de EstadoEl diagrama de estado del UML describe los eventos y estados más relevantes de un objeto, así como su comportamiento ante cada evento.Evento: es un acontecimiento u ocurrencia notable, que desencadena un cambio de estado.Estado: es la condición de un objeto en un momento determinado, o el tiempo que transcurre entre dos eventos.Transición: es una relación entre dos estados. Cuando ocurre un evento, el objeto pasa de un estado al siguiente. .Barrera, Corroppoli, Dans, Ibañez 124 2003
    • Diagrama de Estado Nombre Iniciar Terminar Variables de estado Actividades * Casos típicos (procesos) * Sistemas * VentanasPosibles diagramas * Coordinadores de aplicaciones * Controladores * Transacciones * Dispositivos * Mutadores .Barrera, Corroppoli, Dans, Ibañez 125 2003
    • Diagramas de Clases (I)Cliente Mozo MesaCocinero Adicio- Cocina nista Menú Vajilla Salón .Barrera, Corroppoli, Dans, Ibañez 126 2003
    • Diagramas de Clases (II)Cliente Mozo Mesa Vajilla CocinaCocinero Menú Adicionista Salón .Barrera, Corroppoli, Dans, Ibañez 127 2003