Tm05 modelo de_interacción
•Descargar como PPT, PDF•
0 recomendaciones•1,596 vistas
Este documento presenta información sobre modelado de interacciones entre objetos. Explica conceptos como mensajes, interacciones y diagramas de secuencia y colaboración para representarlas. Incluye ejemplos de diagramas que muestran la secuencia de mensajes intercambiados entre objetos para lograr un propósito. También cubre temas como objetos, líneas de vida y elementos de los diagramas de interacción.
![Mensajes e Interacciones
Los objetos en un sistema O-O interactúan entre
ellos mediante mensajes que solicitan algún servicio
del objeto receptor.
El objeto receptor responde el mensaje a través de
algún método definido y conocido por el objeto
emisor. 1: setAsignaturaEnTutoria( )
: GestorTutorias
4: [enTutoria]
: Profesor
3: enTutoria := estaEnTutoria( )
7: setPeridoActual(PeriodoTutoria)
2: setEnTutoria( )
5: create( )
6: setInicioPerido( )
asignatura : nuevoPeriodoTutoria
TutoriaAsignatura : Periodo
2](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Similar a Tm05 modelo de_interacción
Más de Julio Pari
Más de Julio Pari (20)
Tm05 modelo de_interacción
- 1. Técnicas de Modelamiento Sesión 5 Modelado de Interacciones Prof. César Luza Montero Facultad de Ingeniería de Sistemas e Informática Universidad Nacional Mayor de San Marcos Copyright © 2008, Cesar Luza, Lima-Perú
- 2. Mensajes e Interacciones Los objetos en un sistema O-O interactúan entre ellos mediante mensajes que solicitan algún servicio del objeto receptor. El objeto receptor responde el mensaje a través de algún método definido y conocido por el objeto emisor. 1: setAsignaturaEnTutoria( ) : GestorTutorias 4: [enTutoria] : Profesor 3: enTutoria := estaEnTutoria( ) 7: setPeridoActual(PeriodoTutoria) 2: setEnTutoria( ) 5: create( ) 6: setInicioPerido( ) asignatura : nuevoPeriodoTutoria TutoriaAsignatura : Periodo 2
- 3. ¿ Qué es un Mensaje? Es la especificación de una comunicación entre un objeto emisor y otro que actúa como receptor; con la expectativa de desencadenar en este último, una actividad. Conectar() :MandoADistancia :Televisor Canal(4) 3
- 4. ¿ Qué es una Interacción Una Interacción es el conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto para lograr un propósito. Se modelan mediante diagramas de interacción del UML : GestorT utorias asignatura : nuevoPeriodoTutoria : : Profesor TutoriaAsignatura Periodo setAsignaturaEnTutoria( ) setEnTutoria( ) enTutoria := estaEnTutoria( ) [enTutoria] create( ) setInicioPerido( ) setPeridoActual(PeriodoT utoria) 4
- 5. Diagramas de Interacción Describen una interacción. Dos tipos: Diagramas de Secuencia y Colaboración Diagramas de Secuencia: Destacan el orden temporal de los mensajes Diagramas de Colaboración: Destacan la organización estructural de los objetos participantes. Tienen equivalencia semántica 5
- 6. Ejemplo de Diagrama de Secuencia : GestorT utorias asignatura : nuevoPeriodoTutoria : : Profesor TutoriaAsignatura Periodo setAsignaturaEnTutoria( ) setEnTutoria( ) enTutoria := estaEnT utoria( ) [enTutoria] create( ) setInicioPerido( ) setPeridoActual(PeriodoT utoria) 6
- 7. Ejemplo de Diagrama de Colaboración 1: setAsignaturaEnTutoria( ) : GestorTutorias 4: [enTutoria] : Profesor 3: enTutoria := estaEnTutoria( ) 7: setPeridoActual(PeriodoTutoria) 2: setEnTutoria( ) 5: create( ) 6: setInicioPerido( ) asignatura : nuevoPeriodoTutoria TutoriaAsignatura : Periodo 7
- 8. Elementos fundamentales De forma general el diagrama de Secuencia está formado por: Objetos y líneas de tiempo por objeto Iconos de Mensaje: uno por cada mensaje, entre dos líneas de tiempo Mensaje: nombrados, comúnmente sin numerar De forma general el diagrama de Colaboración está formado por: Objetos y enlaces entre objetos Iconos de Mensaje: uno para varios mensajes Mensajes: nombrados y numerados 8
- 9. Objetos y líneas de vida un objeto cliente : un objeto servidor : cliente servidor mensaje Objetos Icono del Línea de vida mensaje 9
- 10. Mensaje simple Envío de Mensaje simple: Un solo hilo de ejecución El objeto activo pasa el control al objeto pasivo un objeto cliente : un objeto servidor : cliente servidor mensaje 10
- 11. Mensaje de Retorno(Return) Envío de mensaje Retorno Muestra el valor de retorno de un mensaje Debe evitarse ya que un retorno esta siempre implícito al final de un mensaje un objeto cliente : un objeto servidor : cliente servidor mensaje valor de retorno del mensaje 11
- 12. Foco de control Muestra (de forma simbólica) la duración de una acción. un objeto cliente : un objeto servidor : cliente servidor mensaje 1 mensaje 2 duración Foco de mensaje 3 control 12
- 13. Mensaje a si mismo Mensaje a sí mismo: es posible que un objeto se envíe un mensaje a sí mismo un objeto cliente : un objeto servidor : cliente servidor mensaje mensaje a sí mismo 13
- 14. Otros elementos un objeto cliente : cliente un objeto servidor : servidor mensaje(un parametro, otro parametro) Mensaje con resultado = mensaje Mensaje con resultado *mensaje parámetros [condicion] mensaje Indica iteración Si se cumple la condición se envía el mensaje 14
- 15. Utilidad del diagrama de secuencia Para documentar casos de uso Se considera dos tipos de objetos: actor y sistema (caja negra). El diagrama se conoce como Diagrama de Secuencia del Sistema (DSS) Para realizar casos de uso A nivel de análisis, se consideraran actores y objetos del dominio A nivel de diseño, los actores se sustituyen por objetos interfaz Este caso permite encontrar las operaciones de cada clase identificada en el modelo de dominio. 15
- 16. Realización de casos de uso Una Realización de Casos de Uso (RCU) describe como un escenario de un CU es realizado por varios objetos colaborando entre sí. Se representa con diagramas de secuencia, colaboración y de clases. La definición de una RCU se inicia con el Análisis de Casos de Uso (Modelo de Análisis) y se completa con el diseño de casos de uso (Modelo de diseño). El objetivo de una RCU es especificar que clases deben ser construidas para implementar ese caso de uso. realizacion de caso de uso 16
- 17. ¿Qué es el modelo de análisis? Es un modelo conceptual de objetos, que ayuda a refinar los requerimientos y permite a los desarrolladores describir la estructura interna del sistema. El modelo de análisis proporciona una configuración conceptual del sistema que consiste de objetos de : interfaz, entidad e control. 17
- 18. ¿Qué es el modelo de análisis? F01.01 Consulta saldo Cliente I_Cajero C_Gestor_Interfaz Cta_Cliente I_Autenticacion C_Verificador_Autenticacio n 18
- 19. Clase Interfaz Las Clases Interfaz o frontera o “Boundary” se usan para modelar la interacción entre el sistema y los actores. Esta interacción involucra recibir (y presentar) información y peticiones desde usuarios y sistemas externos. Representan la abstracción de ventanas, formularios, paneles, interfaces de comunicación, impresoras, sensores, terminales o dispositivos. 19
- 20. Clase Interfaz Ejemplo: La interfaz de pago es usada para soportar la interacción entre el actor cajero y el caso de uso de Registrar Pago. IU_Pago Cajero 20
- 21. Clases Entidad Las Clases Entidad (Entity) son usadas para modelar la información que tiene permanencia en el tiempo y es persistente. Modelan la información y el comportamiento asociado de algún concepto como una persona, evento u objeto del mundo real. Usualmente muestran la estructura de datos lógica que contribuye a la comprensión de la información que depende el sistema. 21
- 22. Clases Entidad Ejemplo: La clase entidad Pago permite mostrar la información de un pago en la interfaz de pago. consulta IU_Pago Cajero Pago 22
- 23. Clase Controladora Las clases “control” representan la coordinación, secuencia, gestión de transacciones y control de otros objetos. Usualmente se usan para encapsular el control relacionado con un caso de uso específico. También se usan para representar cálculos y derivaciones complejas, como la lógica del negocio que no se puede relacionar con ninguna entidad. La dinámica del sistema se modela en una clase controladora, que se encarga de delegar trabajo a otras clases. 23
- 24. Clase Controladora Ejemplo: La controladora de pagos es responsable de la coordinación entre la interfaz de pagos y la entidad pago. Registrar Crear IU_Pago Controladora Cajero de Pagos Pago 24
- 25. Diagrama de clases de análisis Es un diagrama que muestra las clases de análisis y sus relaciones. Registrar Crear IU_Pago Controladora Cajero de Pagos Pag o 25
- 26. Modelo de Casos de Uso vs. Modelo de Análisis Use-Case Model Analysis Model Se describe usando el lenguaje Se describe usando el lenguaje del del cliente. desarrollador. Es la vista externa del sistema. Es la vista interna del sistema. Se usa a manera de contrato Se usa para que los desarrolladores entre clientes y desarrolladores comprendan como el sistema debe para definir lo que el sistema ser diseñado e implementado. debe y no debe hacer No debe contener redundancias ni Puede contener redundancias e inconsistencias en la interpretación inconsistencias en el enlace con de los requerimientos. los requerimientos. Bosqueja como realizar la Captura la funcionalidad del funcionalidad dentro del sistema. sistema 26
- 27. Proceso de Conversión: Casos de Uso Análisis MODELO DE CASOS DE USO MODELO DE ANÁLISIS «trace» caso de uso (MCU) Realización (MA) Interfaz Gestor/Control Entidad Artefactos del modelo de análisis F01.01 Consulta saldo Diagrama de Cliente I_Cajero C_Gestor_Interfaz Cta_Cliente Clases de Análisis Atómico I_Autenticacion C_Verificador_Autenticacio n
- 28. Modelo de las vistas El modelo de las “4+1 Vistas” Vista lógica Vista de Implementación Analistas – Diseñadores Programadores Estructura Vista de casos de uso Manejo del Sw Usuario final Vista de Proceso Funcionalidad Integradores de sistemas Ingeniero de sistemas Desempeño Topología del sistema, Escalabilidad instalación 28
- 29. Relación entre Vistas… Vista de Casos de Uso Vista Lógica Modelo de Análisis 29
- 30. Relación entre Modelos de distintas vistas Vista Lógica Vista de Casos de Uso Modelo de Análisis <<Trace>> 30
- 31. Entradas y Salidas del Proceso 31
- 32. ¿Qué es el análisis de casos de uso? 32
- 33. ¿Qué es el análisis de casos de uso? 33
- 34. ¿Cómo se hace el análisis de casos de uso? 34
- 35. ¿Cómo se hace el análisis de casos de uso? 35
- 36. Análisis de casos de uso 36
- 37. Encontrando clases en los casos de uso 37
- 38. ¿Cómo son las clases de análisis? 38
- 39. Estereotipos 39
- 40. Clases de límite (Boundary) 40
- 41. Interfases con otros sistemas 41
- 42. El rol de una clase Boundary <<boundary>> <<control>> <<boundary>> Actor <<boundary>> Actor <<entity>> <<entity>> Modela la interacción entre el sistema y su ambiente 42
- 43. Boundary Classes Studentr Register for Courses Course Catalog System RegisterForCoursesFor CourseCatalogSystem m 43
- 44. Clase de Entidad (Entity) 44
- 45. El rol de una clase Entidad Almacenar y manejar información en el sistema 45
- 46. Clase de Control 46
- 47. Rol de una clase Control 47
- 48. Control Classes Una clase control por caso de uso Student Register for Courses Course Catalog System RegistrationController 48
- 49. Encontrando objetos entidad 49
- 50. Filtrando sustantivos 50
- 51. Escenario inscribirse en cursos- crear un horario 51
- 52. Sustantivos del escenario del caso de uso inscribirse en cursos-crear un horario 52
- 53. Filtrando el escenario del caso de uso inscribirse en cursos-crear un horario 53
- 54. Análisis de objetos filtrados en el escenario del caso de uso inscribirse en cursos-crear un horario 54
- 55. Creando clases entidad 55
- 56. Clases entidad identificadas en el escenario del caso de uso inscribirse en cursos-crear un horario 56
- 57. Encontrando clases límite 57
- 58. Candidatos a clases límite en el escenario del caso de uso inscribirse en cursos- crear un horario 58
- 59. Bosquejo de pantalla 59
- 60. Encontrando clases de control 60
- 61. Clases de Control en el caso de uso inscribirse a cursos 61
- 62. Diagrama de Vista de Clases Participantes (VOPC) 62
- 63. Ejemplo de VOPC 63
- 64. Tarea Desarrollar el caso planteado por el profesor 64
Notas del editor
- Invocación de métodos Medio de colaboración entre objetos
- Es importante recordar que la vista arquitectónica de un sistema está compuesta por un conjunto de perspectivas distintas, cada una llamada una vista del sistema. Cada vista se compone a su vez de uno o más modelos generados en las distintas etapas del proceso de desarrollo, por ejemplo, la Vista Funcional o de Casos de Uso contiene el modelo de Casos de Uso, formado por el diagrama general de Casos de Uso y la descripción detallada o especificación de cada uno.
- En el ejemplo es posible observar tanto los modelos como los elementos que conforman cada vista: La vista de casos de uso: formada por el modelo de casos de uso ( Diagrama de Casos de Uso y Descripción detallada de casos de uso) La vista Lógica: Contiene el modelo de análisis, el cuál a su vez contiene las realizaciones de Casos de Uso, y por cada realización, los correspondientes diagramas de clase, colaboración y secuencia que dan forma a los escenarios dentro del caso de uso. Es importante mencionar que la vista lógica no sólo está formada por el modelo de análisis, sin embargo, se muestra este único modelo porque por el momento no se ha llegado a la disciplina de diseño, donde se genera un modelo adicional al modelo de análisis.
- Una realización de casos de uso describe cómo un caso de uso en particular es modelado dentro del modelo de análisis primero y después dentro del modelo de diseño, en términos de objetos colaboradores. Una realización de caso de uso reúne los casos de uso del modelo de casos de uso con las clases y relaciones definidas dentro de los modelos de la vista lógica. Esto se logra porque en una realización de caso de uso se especifica qué clases deben ser construidas para implementar cada caso de uso. En UML, las realizaciones de caso de uso se representan con colaboraciones estereotipadas. El símbolo para una colaboración es una elipse que contiene el nombre de la colaboración. El símbolo para una realización de caso de uso es una versión con líneas punteadaas del símbolo de colaboración. Es importante entender que una realización de caso de uso dentro del modelo de diseño o análisis puede ser rastreada (traced) hacia el correspondiente caso de uso dentro del modelo de casos de uso. Para ello se dibuja una línea punteada con una flecha en forma de triángulo, desde la realización del caso de uso hacia el correspondiente caso de uso en el modelo de casos de uso. Dentro de UML, una realización de caso de uso puede representarse utilizando un conjunto de diagramas que modelan el contexto de la colaboración (las clases/objetos que implementan un caso de uso y sus relaciones –diagrama de clases), y las interacciones de las colaboraciones ( Cómo estas clases/objetos interactúan para desarrollar la colaboración –diagramas de colaboración y diagramas de secuencia). El número y tipo de diagramas que se utilizan depende de qué se necesita representar para proporcionar la imagen completa de la colaboración y, además, de los lineamientos establecidos para el proyecto en desarrollo.
- Esta gráfica resume lo que ya se había presentado anteriormente: el análisis de casos de uso no sólo toma información del modelo de casos de uso, sino que puede utilizar información del glosario de términos, el modelo del dominio, descripción del problema, herramientas para levantamiento de información y especificación suplementaria. .
- Una vez analizado el caso de uso tenemos los primeros elementos conceptuales del sistema: las clases del análisis y sus correspondientes colaboraciones. A medida que analizamos más y más casos de uso, aparecen nuevas clases y las existentes se complementan.
- En este ejemplo queda claro el papel de las clases boundary o interfase: sirven como medio de interacción entre el sistema y los actores que se encuentran en el medio ambiente dentro del cual se ejecuta el sistema. En este caso los objetos de las clases boundary pueden representar medios para comunicarse con otro sistema de software, un dispositivo o un actor humano.
- Por regla general, al menos una clase boundary sirve como medio de comunicación entre los un actor y el correspondiente caso de uso.
- Normalmente el número de clases Entidad variará dependiendo de los conceptos que requieren almacenamiento persistente dentro del caso de uso. Igual que las clases boundary, las clases entidad sufren un proceso de refinamiento a medida que se ubica a la misma clase entidad dentro de distintas realizaciones de caso de uso.
- Por regla general se trata de encapsular la lógica de control de un caso de uso dentro de una clase Conttrol. Suele ser un buen hábito de diseño utilizar únicamente una clase control por cada caso de uso, y así encapsular en un sólo elemento la lógica del caso de uso correspondiente.
- Este ejemplo muestra una técnica básica para descubrir los elementos susceptibles de ser modelados dentro de una clase entidad. Los elementos en rojo han sido descartados. La leyenda que aparece entre paréntesis indica la razón. Algunas de estas razones pueden ser: el sustantivo es un atributo, representa acciones, representa un objeto límite o de interfase, entre otras.
- Aunque se presenta un diagrama VOPC simple, la idea en general es presentar un diagrama de clases completo donde se muestren las asociaciones entre clases, los atributos, multiplicidad, roles, etc.