Tema 5 Introducción a UML. Ingeniería del Software I

Documentos relacionados
Tema 4b: Introducción a UML

Introducción a UML. Mitos sobre UML

Prof. Mariano Mancuso. Sistemas de información y control diagrama de clases

Tema 6: Principios de diseño orientado a objetos

Ingeniería de Software

Unified modeling language

Principios de la Tecnología de Objetos

Tema 1. Introducción a UML C H R I STO PHER E X P Ó S I TO I Z Q U I ERDO A I R A M E X P Ó S I TO M Á R Q UEZ I S R A E L LÓ P EZ P L ATA M A R Í A

Modelo Dinámico del Diseño del Software y Representación en UML. UNIDAD 9 Análisis y Diseño de Sistemas de Información

1. Asignar Responsabilidades a componentes de software es la habilidad más importante del AOO. Porque:

UML. (Unified Modeling Language) Lenguage Unificado de Modelado

CLASE 3: UML DIAGRAMAS CASOS DE USO. Universidad Simón Bolívar. Ingeniería de Software. Prof. Ivette Martínez

TEMA 6: INTRODUCCIÓN A UML

Tema 4e: Proceso Unificado: Análisis

UML Unifield Modeling Languaje

CAPÍTULO III - UML Y LOS PROCESOS DE DESARROLLO DE SOFTWARE

Un caso de uso es una tarea que debe poder llevarse a cabo con el apoyo del sistema que se está desarrollando, se representa mediante un óvalo.

Guía práctica de estudio 09: UML

1. INTRODUCCIÓN AL UML...1

Introducción a UML Información tomada de: - Jacobson et al, El proceso unificado de desarrollo de software

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA ESCUELA DE CIENCIAS Y SISTEMAS

Lenguaje de Modelamiento Unificado.

UML El Lenguaje Unificado de Modelado Grady Booch, Jim Rumbaugh e Ivar Jacobson

El Lenguaje Unificado de Modelado (UML)

Análisis y Diseño de Sistemas

Contenido. 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo

PROGRAMACIÓN ORIENTADA A OBJETOS. Dr. Noé Alejandro Castro Sánchez

TRABAJO PRÁCTICO 7: OBJETOS

Elementos Diagramas de Clases Clase:

Los diagramas de clases y de objetos sirven para modelar diversos aspectos estructurales o estáticos de un sistema: Modelado - Vocabulario del Sistema

Interacción Persona - Ordenador

Sesión 1. Porque es útil usar UML Sesión 2. Casos de uso Modelo del Negocio Sesión 3. Diagramas de Casos de Uso Sesión 4. Diagrama de Actividad

1. Preparar al estudiante para desarrollar aplicaciones de software utilizando un enfoque orientado a objetos.

Ingeniería a de Software CC51A

INGENIERÍA WEB. Dr. Mario Rossainz López Fac. de Cs. de la Computación Benemérita Universidad Autónoma de Puebla Otoño de 2017

Análisis y Diseño de Sistemas

Centro Asociado Palma de Mallorca Tutor: Antonio Rivero Cuesta

Generación de código a partir de UML

Modelo de Casos de Uso

Programación Orientada a Objetos

Sistemas de Información II. Análisis de Sistemas Orientado a Objetos

Modelado Visual con UML.

Introducción a la Orientación a Objetos

Diagramas De Casos De Uso

Programación Orientada a Objetos. Conceptos Básicos

UNT INGENIERIA INDUSTRIAL INGENIERIA DE SOFTWARE

Desarrollo Orientado a Objetos en Métrica v. 3

Capítulo 16. Diagrama de Clases UML

TEMA 4. PROCESO UNIFICADO

Analista Programador MySQL. Informática y Programación

CIDE, SA. RIF: J NIT: MODELO FUNCIONAL

octubre de 2007 Arquitectura de Software


INGENIERIA DE SOFTWARE ING. FRANCISCO RODRIGUEZ

CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES SYLLABUS DE INGENERIA DE SOFTWARE I

Asignatura: Ingeniería del Software II Profesor: José Merseguer. Departamento de Informática e Ingeniería de Sistemas

12/08/2017. Casos de uso. Casos de uso. Casos de uso. Casos de uso

Diseño Basado en Componentes. UML aplicado al diseño basado en componentes. Tabla de contenidos. Introducción a UML. Definición e historia

Diagramas de Secuencia

Documentación de Requisitos con Casos de Uso

DIAGRAMAS UML ANDRÉS ESTEBAN MARTÍNEZ HUTA CICLO DE VIDA DEL SOFTWARE GLORIA CECILIA RÍOS MUÑOZ

Qué Necesita el Usuario

Capacitación adquirida por el alumno al finalizar este modulo

OO - UML ING. DE SOFTWARE. Es un enfoque sistemático del desarrollo, operación, mantenimiento y retiro del software" Lewis

diagramas de comportamiento con UML.

12/08/2017. Diagrama de secuencia. Diagrama de secuencia. Diagrama de secuencia. Diagrama de secuencia

Para esta práctica usaremos los diagramas de casos de uso, diagramas de secuencia, y los diagramas de clase.

gestión para una empresa de autobuses que se dedica al transporte regional, nacional e internacional de viajeros. Las

Análisis y Diseño de Sistemas Orientado a Objeto. Captura y Análisis de Requerimiento

Capítulo 4 Lenguaje UML

Programación orientada a objetos Semestre 6 Fascículo No. 2

David Pinelo Marzo Abril de 2009

Tema 2. Casos de Uso C H R I STO PHER E X P Ó S I TO I Z Q U I ERDO A I R A M E X P Ó S I TO M Á R Q UEZ I S R A E L LÓ P EZ P L ATA M A R Í A B E L

Lenguaje Unificado de Modelado UML

UML. Diagrama de Casos de Usos. Prof. Daniel Riesco

Diseño. Diseño. Interacción. Aspectos comunes en interacción. Diagramas de Interacción. Curso de Arquitecturas de Software

INGENIERÍA DEL SOFTWARE

CASOS DE USO Exploración de Requerimientos

Crear diagramas basados en UML para la representación de la solución a un problema mediante el Paradigma Orientado a Objetos.

Diagramas de Casos de Uso. Ingeniería del Sw-II, José Merseguer

Tema: Herramientas UML, Análisis y diseño UML

OMG UML 2.0 Marcando un hito en el desarrollo de software

UML y UP. Programa de Estudio.

Metodologías para Sistemas Multi-agente

UNIVERSIDAD RICARDO PALMA FACULTAD DE INGENIERIA EAP INGENIERIA INFORMATICA CICLO ACADEMICO 2003 II SILABO

Tema: Herramientas UML, Análisis y diseño UML

UML: Un Lenguaje de Modelo de Objetos

Tema: Herramientas UML, Análisis y diseño UML

INDICE CARTAS DESCRIPTIVAS S3

Diagrama de Clases I: asociaciones

Fundamentos de Ingeniería de Software. Introducción a Orientación a Objetos Contenido

Análisis y Diseño del Software. El Lenguaje Unificado de Modelado UML 2.0

Especificación de Requerimientos <Nombre del Proyecto> Nombre del Grupo de Desarrollo o Asignatura Nombre del Autor

Tema 13 Modelos de Representación de Diagramas

Modelado Estático Básico. Diseño de Software Avanzado Departamento de Informática

Análisis y Negociación de Requisitos

CLA. Diagramas de clases en Métrica V3

Contenido. 1 Qué es un diagrama de clase? 2 Elementos de un diagrama de clase. 3 Clase, atributo, método y visibilidad. 4 Agregación y composición

Guía del Curso Analista Programador Java: Business Apps Expert

UML: Lenguaje Unificado de Modelado

Transcripción:

Tema 5 Introducción a UML Ingeniería del Software I feliu.trias@urjc.es

UML Unified Modeling Language (Lenguaje unificado de modelado) Mitos sobre UML UML es un lenguaje de programación Aprender UML es aprender el paradigma de objetos. UML es una metodología de desarrollo.

Características Generales Lenguaje Características generales: Incluye conceptos semánticos, notación y reglas de creación de diferentes tipos de diagramas Permite capturar información acerca de la estructura estática y el comportamiento dinámico de un sistema Lenguaje de modelado visual de propósito general usado para: Especificar Modelos precisos, no ambiguos, completos Visualizar Representar y comunicar ideas Construir Trasladar a un lenguaje de programación Documentar Los artefactos construidos durante un proyecto de desarrollo de un sistema software

Lenguaje = sintaxis + semántica Unificado a través de: Características Generales Unificado Métodos y notaciones históricas integradas Usado en múltiples etapas del ciclo de desarrollo (de requerimientos a implementación) Gran diversidad de dominios de aplicación Amplia variedad de lenguajes y plataformas de implementación representables Aplicable en diferentes procesos de desarrollo

Características Generales Modelado Qué es un modelo? Una abstracción que representa algún aspecto de la realidad Una representación en algún medio que captura los aspectos importantes del sistema modelado desde un determinado punto de vista Un modelo de un sistema software es realizado en un lenguaje de modelado Propósito de los modelos Capturar y precisar requerimientos de un dominio de conocimiento, que sea comprensible por todos los stakeholders del proyecto. Pensar sobre un diseño de un sistema. Capturar decisiones de diseño de un sistema. Explorar posibles soluciones a un problema económicamente. Generar productos de trabajo útiles. Documentar. E = M * C 2

Breve evolución histórica Evolución: Oct. 1994: G. Booch y J. Rumbaugh se unen en Rational. Intentan unificar OMT (Object Modeling Tool) y Booch (método) Oct. 1995: I. Jacobson se une a Rational Unified Method v0.8 Nov. 1997: OMG (Object Management Group) aprueba UML (v1.1) 2003: versión 1.5 de UML Oct. 2004: versión 2.0 de UML 2005: convertido en estándar ISO/IEC 19501:2005 Information technology Open Distributed Processing Unified Modeling Language (UML) Version 1.4.2. Cambios entre versiones: Refinamiento y extensión de modelos Ampliación de semántica Cambio en las restricciones de uso de elementos en modelos

Breve evolución histórica

Influencias

Participantes en UML 1.0 Rational Software Grady Booch, Jim Rumbaugh y Ivar Jacobson Digital Equipment Hewlett-Packard i-logix David Harel IBM ICON Computing Desmond D Souza Intellicorp and James Martin & co. James Odell MCI Systemhouse Microsoft ObjecTime Oracle Corp. Platinium Technology Sterling Software Taskon Texas Instruments Unisys

Vistas de UML Qué es una vista? Una vista es un subconjunto de construcciones de modelado que se enfocan en un aspecto particular del sistema Proyección del sistema completo en un modelo Cada vista cuenta con uno o más diagramas representativos Las vistas pueden agruparse en tres áreas: Estructural Comportamiento dinámico Gestión del modelo

Vistas de UML Clasificación estructural Describe los elementos del sistema (clasificadores) y sus relaciones Clasificadores más comunes: Clases Casos de Uso Componentes Nodos Vistas y diagramas asociados: Vista Estática Diagrama de clases Diagrama de objetos Vista de Casos de uso Diagrama de casos de uso Vista de Implementación Diagrama de componentes Diagrama de despliegue

Vistas de UML Comportamiento dinámico Describe el comportamiento del sistema a través del tiempo Vistas y diagramas asociados: Vista de Interacción: modela como interactúan los objetos para realizar una funcionalidad del sistema Diagrama de colaboración Diagrama de secuencia Vista de Máquina de estados: modela el ciclo de vida de una instancia de una clase en estados y transiciones. Diagrama de transición de estados Vista de Actividades: modela flujos de trabajo (workflows) Diagrama de Actividades 12

Vistas de UML Gestión del modelo Describe la organización de los modelos en unidades jerárquicas Permite manejar la complejidad mediante la identificación de agrupaciones de clasificadores Elementos utilizados: Paquetes Subsistemas Modelos

Mecanismos de extensión Permiten adaptar los elementos de modelado asignándole una semántica particular. Estereotipos: Extienden la semántica del elemento sobre el que se aplica Permite representar una variación de un elemento existente que posee otra intención, o distinción de uso Puede indicarse textualmente (entre << y >>) o gráficamente Valores etiquetados Extiende las propiedades de un elemento de UML, permitiendo añadir nueva información en la especificación del elemento Cadenas con el nombre de la etiqueta, un signo igual y un valor Restricciones Notación matemática formal OCL Lenguaje de programación o pseudocódigo

Mecanismos de extensión Ejemplo

Áreas, vistas y diagramas

Áreas, vistas y diagramas Otra clasificación (UML 1.5) Diagramas estáticos (o estructurales *) Diagramas de clases Diagramas de objetos Diagramas de componentes Diagramas de despliegue Diagramas dinámicos (o de comportamiento) Diagramas de casos de uso* Diagramas de secuencia Diagramas de colaboración Diagramas de estados Diagramas de actividades

Áreas, vistas y diagramas Otra clasificación (UML 2.0)

Vista estática Propósito: Capturar la estructura del sistema en base a elementos (clasificadores) que lo definen Es la base sobre la que se construyen las otras vistas Diagramas: Diagrama de Clases Diagrama de Objetos

Vista estática Elementos Clasificador es un concepto discreto en el modelo que tiene identidad, estado, comportamiento, y relaciones Tipos de Clasificadores Elementos del Sistema: Clase Interfaz Tipos de datos Conceptos de Comportamiento: Caso de Uso Conceptos del entorno: Actor Estructuras de implementación: Componente Nodo Subsistema

Vista estática Elementos Clase = Conjunto de objetos con estructura, comportamiento, relaciones y semántica común. Objeto = estructura + operaciones + estado interno + identidad Un objeto es una instancia de una clase. Ejemplos algo físico Avión algo del negocio Pedido un concepto lógico Horario algo de la aplicación Window, Botón, Menú algo del comportamiento Tarea, Proceso

Diagrama de clases El diagrama de clases representa la vista estática de un sistema software Los elementos que aparecen en este diagrama son aquellos conceptos que tienen significado dentro de una aplicación Elementos principales de este diagrama: Clasificadores: elementos que describen cosas Relaciones entre clasificadores La definición de cada concepto del mundo real se identifica con una clase de este diagrama

Clase: se representa en un rectángulo con tres compartimientos nombre de la clase atributos de la clase operaciones de la clase Diagrama de clases: Clase Atributos Policia -Num_Placa : int -Nombre -Apellidos +Apodo -AñosServicio : int = 0 -Condecoraciones -Puntería -Experiencia #Patrullar() -Entrenar() +MostrarCondecoraciones() Nombre de la clase Tipos de los atributos Valor inicial {<10} Restricción sobre el valor Operaciones

Diagrama de clases: Visibilidad Determina el nivel de encapsulamiento de los elementos de una clase (-) Privado: Los atributos/operaciones son visibles solo desde la propia clase. (#) Los atributos/operaciones protegidos están visibles para la propia clase y para las clases derivadas de la original (+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulación) Visibilidad + público # protegido - privado

Las relaciones entre clasificadores son: Asociación (conocimiento) Agregación / Composición Generalización Dependencia Realización Diagrama de clases: Relaciones entre clasificadores Enlace: Instancia de una asociación Lista ordenada de referencias a objetos

Diagrama de clases: Relaciones entre clases Asociación: Conexión semántica entre instancias de clases Proporciona una conexión para el envio de mensajes Multiplicidad 0..1 N..M 0..* 3..* 1..* 2..5 1 3..4, 6..* * roles Dirección de lectura de la relación Navegabilidad (uni/bi-direccional) Policia -Num_Placa : int +Apodo -Puntería -Experiencia #Patrullar() -Entrenar() +MostrarCondecoraciones() -perseguidor 1..* Persigue4 -delincuente 1..* Ladrón -IDLadron : int +Apodo -Tipo : int = 0 -Encarcelaciones -Puntería #Robar() -Escapar() +MostrarHistorial() Multiplicidad Nombre de la relación

Diagrama de clases: Asociación: casos especiales Presentacion Asociación como clase -Fecha -Hora * * Teatro Obra Asociación calificada Presentacion Num_Butaca 1 1..* Entrada Asociación ordenada Presentacion 1 {ordered} 0..1 1..* Diapositiva Restricción Cuenta * * or * 1 Persona Empresa

Diagrama de clases: Relaciones entre clases Agregación: relación entre un todo y sus partes Lógica: la parte puede pertenecer a varios agregados Universidad 1..* 1..* Estudiante Física (o composición): las partes sólo existen asociadas al compuesto (acceso a través de él) Universidad 1 1..* Departamento

Diagrama de clases: Relaciones entre clases Consideraciones sobre la composición Una composición es una forma de asociación más fuerte en la cual el compuesto es responsable de gestionar sus partes, por ejemplo asignación y desasignación La composición implica tres cosas: Dependencia existencial. El elemento dependiente desaparece al destruirse el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo Hay una pertenencia fuerte. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene Los objetos contenidos no son compartidos, esto es, no hacen parte del estado de otro objeto

Diagrama de clases: Relaciones entre clases Dependencia: Indica una relación semántica entre dos o más elementos del modelo en la cual un cambio al elemento proveedor puede requerir un cambio o indicar un cambio en el significado del elemento cliente en la dependencia Ladrón -IDLadron : int +Apodo -Tipo : int = 0 -Encarcelaciones -Puntería #Robar() -Escapar() +MostrarHistorial() «uses» Estereotipo -material -fuerza +usar() +aprenderuso() Mecanismos de extensión de UML Herramienta Estereotipos Valores etiquetados Restricción <<excepción>> {versión=3.1} {edad>18}

Diagrama de clases: Relaciones entre clases Generalización: Relación taxonómica entre una descripción general y otra más específica que la extiende Relación es un tipo de Representación del concepto de herencia Policia -Num_Placa : int +Apodo -Puntería -Experiencia #Patrullar() -Entrenar() +MostrarCondecoraciones() Patrullero +Riesgo -Pistola Criminalista -Origen +Especialidad

Diagrama de clases: Relaciones entre clases Realización: Es una relación que implica que la parte realizante cumple con una serie de especificaciones propuestas por la clase realizada Situaciones de aplicación: Interfaces y las clases y componentes que lo implementan Casos de uso y colaboraciones que lo realizan «interfaz» MiembroSeguridad Policia -Num_Placa : int +Apodo -Puntería -Experiencia #Patrullar() -Entrenar() +MostrarCondecoraciones()

Diagrama de clases: Interfaces Describen un protocolo de comportamiento sin especificar su implementación. Contienen operaciones pero no atributos. Una interfaz puede ser implementada por varias clases

Diagramas de Clases vs. Diagramas de Objetos Ambos pertenecen a dos vistas complementarias del modelo Diagrama de Clases: muestra la abstracción de una parte del dominio Diagrama de Objetos: representa una situación concreta del dominio Banco Cliente 1 * 1 * Cuenta cliente01 : Cliente cta0101 : Cuenta unbanco : Banco cta0201 : Cuenta cliente02 : Cliente cta0202 : Cuenta

Ejercicio Se desea modelar el sistema de control de un reproductor de MP3 que tiene las siguientes características: Un reproductor tiene una marca y modelo determinado. Las operaciones que permite este aparato son: escuchar música (de la memoria), escuchar la radio o configurar el dispositivo El módulo de memoria permite: conocer la capacidad de la memoria, el número de canciones almacenadas, seleccionar una canción (aleatoriamente o por su título) y borrar una canción De cada canción se conoce su título, intérprete, duración, tamaño que ocupa, y tipo de compresión (en kbps) El módulo de radio permite: seleccionar un dial concreto (preseleccionado o manualmente), cambiar de AM a FM y viceversa y preseleccionar emisoras. Cada emisora se caracteriza por estar en una banda (AM/FM), por un número de frecuencia y por una cobertura El módulo para la configuración del equipo permite: modificar el brillo y colores del display, consultar el estado de la batería y modificar la ecualización del sonido. Diseñar el diagrama de clases UML correspondiente a estas especificaciones

Vista de Casos de Uso Diagramas de casos de uso: Capturan los requerimientos funcionales del sistema Describen la forma de usar el sistema tal como se la ve desde el exterior Visión de caja negra del sistema. No es un modelo orientado a objetos. Particiona la funcionalidad del sistema en unidades discretas: los casos de uso. Concepto introducido por I.Jacobson en OOSE (Object Oriented Software Engineering) Diagramas de Casos de Uso: Actores + Caso de uso

Representa algo que interactúa con el sistema Puede ser humano u otro sistema (externo) Reside fuera del sistema sirve para describir el entorno del sistema Describe un rol que asume un usuario La misma persona física puede asumir distintos roles Ejemplos: Cliente del Banco Cajero Pasarela bancaria Sistema de sensores Diagrama de Casos de Uso Actor Cliente del Banco

Diagrama de Casos de Uso Caso de uso Secuencia de transacciones realizadas por el sistema que brinda un resultado de valor a un actor Describe una forma de utilizar el sistema o una razón por la que el usuario interactúa con el sistema Funciones: Capturan requisitos funcionales del sistema Estructuran los modelos de objetos en vistas manejables Un caso de uso puede tener varios caminos de acción o escenarios Los casos de uso sirven como hilo conductor del proceso de desarrollo (en el PUD)

Diagrama de Casos de Uso Ejemplo Cajero automático (CA) Extracción (from Extraccion) Cliente (f rom Actors) Transferencia Sistema Central (f rom Actors) Depósito Operador (f rom Actors) Administración

Diagrama de Casos de Uso Descripción textual CU Extracción Camino Estandard 1 Un mensaje de bienvenida está en espera en la pantalla del CA. 2 El cliente inserta su tarjeta en el CA. 3 El CA lee el codigo de la banda magnética y verifica que sea aceptable. 4 Si la tarjeta es aceptable, el CA solicita al cliente su código PIN. 5 El cliente ingresa su código PIN. 6 Si el código PIN es correcto, el CA solicita al cliente el tipo de transacción a realizar. 7 El cliente selecciona <extracción> y el CA envía el código PIN al Sistema bancario solicitando los datos de la cuenta del cliente. 8 Los datos de la cuenta recibidos se despliegan en la pantalla. 9 El cliente selecciona una cuenta y el monto a extraer. 10 El CA envia al sistema bancario el requerimiento de extracción. 11 El CA preparan los billetes a ser dispensados. 12 El CA imprime el comprobante del movimiento. 13 Los billetes son dispensados al cliente.

Diagrama de Casos de Uso Descripción textual RF- <id del requisito> Versión Autores Fuentes Objetivos asociados Descripción Precondición Secuencia Normal Postcondición Excepciones 3 Rendimiento Paso Cota de tiempo 1 n segundos 2 n segundos Frecuencia esperada Importancia Urgencia Comentarios <nombre del requisito funcional> <numero de versión y fecha> <autor> <fuente de la versión actual> <nombre del objetivo> El sistema deberá comportarse tal como se describe en el siguiente caso de uso { concreto cuando <evento de activación>, abstracto durante la realización de los casos de uso <lista de casos de uso>} <precondición del caso de uso> Paso Acción 1 {El <actor>, El sistema} <acción realizada por el actor o sistema>, se realiza el caso de uso < caso de uso RF-x> 2 Si <condición>, {el <actor>, el sistema} <acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x> 3 4 5 6 n <postcondición del caso de uso> Paso Acción 1 Si <condición de excepción>,{el <actor>, el sistema} }<acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>, a continuación este caso de uso {continua, aborta} 2 <nº de veces> veces / <unidad de tiempo> {sin importancia, importante, vital} {puede esperar, hay presión, inmediatamente} <comentarios adicionales>

Inclusión Diagrama de Casos de Uso Relaciones Secuencias comunes a varios casos de uso Procesar Tarjeta <<include>> <<include>> <<include>> Extracción Transferencia Depósito

Extensión: Diagrama de Casos de Uso Relaciones Partes opcionales de un caso de uso Extracción <<extend>> <<extend>> Estadística Extracción Monitoreo Extracción

Generalización: Diagrama de Casos de Uso Relaciones Distintas variantes de un caso de uso. ( es un tipo de ) Extracción Extracción Pesos Extracción Dólares

Diagrama de Casos de Uso Ejemplo <<include>> Hacer Pedido <<extend>> <<include>> <<include>> Silicitar Catálogo Suministro de datos de clientes Pedir Producto Pagar Pagar al contado Acordar Crédito

Vista de Interacción Representa como interactúan cooperativamente los objetos para implementar el comportamiento definido por los casos de uso Colaboración Interacción entre un conjunto de objetos para implementar un comportamiento del sistema. Una colaboración <<realiza>> la funcionalidad definida en un casos de uso Interacción Una interacción es un conjunto de mensajes que se intercambian dentro del contexto de una colaboración por instancias de clases (objetos) a través de enlaces (instancias de asociación)

Vista de Interacción Diagramas de Colaboración Énfasis en la distribución física y relaciones de los objetos 5: cuenta destino 3: cantidad 1: transferencia 6: transferencia (cuenta, cantidad) 9: no hay fondos : Cliente del banco : Interfaz de cajero : Transacción 2: teclee cantidad 7: reintegro (cantidad) 4: teclee cuenta destino 8: no hay saldo 10: no hay fondos cuentaorigen : Cuenta

Vista de Interacción Diagramas de Secuencia Énfasis en la secuencia cronológica de los mensajes : Encargado :WInPréstamos :Socio :Video :Préstamo prestar(video, socio) verificar situación socio verificar situación video registrar préstamo entregar recibo

Vista de Máquina de Estados Describe el comportamiento dinámico de los objetos, modelando su ciclo de vida: Autómatas finitos con estados y transiciones Cada objeto se trata en forma aislada, el que se comunica con el resto del mundo detectando eventos y respondiendo a ellos. Es útil modelar solo para objetos con comportamiento estadodependiente Uso de Diagramas de Transición de Estados

Diagramas de Transición de Estados Cada objeto está en un estado en cierto instante El estado describe un período de tiempo caracterizado por: Conjunto de valores de atributos y relaciones del objeto Período de tiempo durante el que se espera que ocurra un evento Período de tiempo durante el cual el objeto realiza una actividad El estado en el que se encuentra un objeto determina su comportamiento Cada objeto sigue el comportamiento descrito en el diagrama de transición de estados asociado a su clase La transición entre estados es instantánea y se debe a la ocurrencia de un evento

Diagramas de Transición de Estados Estados y Transiciones Evento [condición] / Acción A B El evento se considera instantáneo

Ejemplo: Pila (TAD) Diagramas de Transición de Estados pop error crear pila Pila Vacía borrar pila push pop (size = 1) pop (size > 1) push (size+1 <> full) Pila no vacía ni llena borrar pila evento (cond) acción push error Pila llena push (size+1 = full) pop borrar pila

Acontecimiento significativo que tiene localización en tiempo y espacio No tiene duración. Instantáneo Tipo de eventos Diagramas de Transición de Estados Eventos Señal: comunicación asíncrona entre objetos Llamada: invocación sincrónica de método del objeto que recibe el evento Cambio: satisfacción de una condición lógica que depende de valores de un atributo Tiempo: instante absoluto, o lapso transcurrido Pueden modelarse con clases y jerarquías

Diagramas de Transición de Estados Eventos

Diagramas de Transición de Estados Acciones Una acción es un cómputo atómico y breve: una sentencia de asignación una operación aritmética el envío de una señal a otro objeto la invocación de una operación propia asignación de valores de retorno creación o destrucción de objetos una secuencia de acciones simples Acciones específicas de entrada, salida, durante, un estado o por un evento estado A entry: acción por entrar exit: acción por salir do: acción mientras en estado on evento: acción

Diagramas de Transición de Estados Estados Compuestos

Vista de Actividades Variante de la máquina de estados para modelar flujos de trabajo Utilización de diagramas de actividad Caso particular de los diagramas de estado Los estados representan estados de actividad no de un objeto

Diagrama de Actividades Elementos

Diagrama de Actividades Calles y flujo de objetos

Vista de Implementación Tipo de vista física Modela el empaquetado físico del sistema en unidades reutilizables llamadas componentes Componente una unidad física de implementación con interfaces definidas pensada para ser utilizada como parte reemplazable del sistema. Cada componente implementa una o más clases del diseño Incluyen código fuente, binario, o ejecutable Los componentes se vinculan por relaciones de dependencia Se utilizan diagramas de componentes

Diagrama de Componentes

Vista de Despliegue Modela la disposición física de los recursos de ejecución computacional Nodo: es un objeto físico de ejecución que representa un recurso computacional. Pueden tener estereotipos (CPU, memorias, disco duro, etc.) Las asociaciones entre nodos representan líneas de comunicación. Se representa con diagramas de despliegue

Diagrama de Despliegue

Diagrama de Despliegue DB Server * * * * APP Server * Servlets * JSP * JDBC Cliente * Web Browser

Vista de Gestión La Vista de Gestión del modelo está compuesta por paquetes y relaciones de dependencia entre paquetes Paquete: es una unidad de organización del modelo Los paquetes ofrecen un mecanismo general para la organización de los modelos / subsistemas agrupando elementos de modelado Los paquetes contienen elementos del modelo como clases, diagramas de casos de uso, interacciones, etc. Los paquetes tambien pueden contener otros paquetes

Vista de Gestión Todos los elementos del modelo deben pertenecer a un paquete Los paquetes pueden organizarse según el criterio del diseñador: Por la vista (estática, casos de uso, etc.) Por subsistema Por etapa del ciclo de desarrollo. Una buena organización refleja la arquitectura de alto nivel del sistema.

Tema 5 Introducción a UML Ingeniería del Software I feliu.trias@urjc.es