Agenda. Qué es UML? Escenarios: Casos de Usos. CU son un puente hacia la transición entre requerimientos funcionales y objetos.

Transcripción

1 Capítulo 2 y 4: Requerimientos y Modelo Funcional

2 Agenda Qué es UML? Escenarios: Una gran forma de establecer comunicación con el cliente Casos de Usos Abstracciones de escenarios CU son un puente hacia la transición entre requerimientos funcionales y objetos.

3 Qué es UML? Unified Modeling Language Convergencia de diferentes notaciones usadas en métodos O.O., principalmente OMT (James Rumbaugh and collegues), OOSE (Ivar Jacobson), Booch (Grady Booch) Ellos también desarrollaron el Rational Unified Process, el cual llegó a ser Unified Process en años en GE Research, donde desarrolló OMT, junto con (IBM) Rational en 1994, herramienta CASE OMTool En Ericsson hasta 1994, desarrolló los casos de uso y la herramienta CASE Objectory, en IBM Rational desde 1995, Desarrolló el método Booch ( nubes ), ACM Fellow 1995, y IBM Fellow com/

4 UML Estándar no propietario para modelar sistemas Versión Actual: UML 2.2 Información en Herramientas Comerciales: Rational (IBM),Together (Borland), Visual Architect (Visual Paradigm), Enterprise Architect (Sparx Systems) Herramientas Software Libre ArgoUML, StarUML, Umbrello (for KDE), PoseidonUML Ejemplo de herramientas de investigación: Unicase, Sysiphus Basadas en un modelo de proyecto unificado para modelación, colaboración y organización de proyecto

5 Notación Básica en UML: Primer Resumen UML provee una amplia variedad de notaciones para modelar muchos aspectos de sistemas de software En la última clase, hicimos una primera pasada sobre: Modelo Funcional: diagramas de casos de uso Modelo Objeto: diagramas de clases Modelo Dinámico: diagramas de secuencia, de estado Ahora veamos con mas detalle

6 Historia Reciente de UML Marzo 2003: Julio 2005: Noviembre 2007: Febrero 2009 UML 1.5 UML 2.0 UML UML 2.2

7 Un Ejemplo Típico de Actividades de Ciclo de Vida del Software Elicitación de Requerimientos Análisis Diseño de Sistema Diseño Detallado Implementación Testing

8 Actividades de Ciclo de Vida del Software...y sus modelos Elicitación de Requerimientos Análisis Diseño de Sistema Diseño Detallado Implementación Testing Modelo de Caso de Uso

9 Actividades de Ciclo de Vida del Software...y sus modelos Elicitación de Requerimientos Análisis Diseño de Sistema Diseño Detallado Implementación Testing Expresado en términos de Modelo de Caso de Uso Objetos de Dominio de Aplicación

10 Actividades de Ciclo de Vida del Software...y sus modelos Elicitación de Requerimientos Análisis Diseño de Sistema Diseño Detallado Implementación Testing Expresado en términos de Estructura -do por Modelo de Caso de Uso Objetos de Dominio de Aplicación Subsistemas

11 Actividades de Ciclo de Vida del Software...y sus modelos Elicitación de Requerimientos Análisis Diseño de Sistema Diseño Detallado Implementación Testing Expresado en términos de Estructura -do por Realizado por Modelo de Caso de Uso Objetos de Dominio de Aplicación Subsistemas Objetos del Dominio de Solución

12 Actividades de Ciclo de Vida del Software...y sus modelos Elicitación de Requerimientos Análisis Diseño de Sistema Diseño Detallado Implementación Testing Modelo de Caso de Uso Expresado en términos de Objetos de Dominio de Aplicación Estructura -do por Subsistemas Realizado por Objetos del Dominio de Solución Implementado por class... class... class... Código Fuente

13 Actividades de Ciclo de Vida del Software...y sus modelos Elicitación de Requerimientos Análisis Diseño de Sistema Diseño Detallado Implementación Testing Modelo de Caso de Uso Expresado en términos de Objetos de Dominio de Aplicación Estructura -do por Subsistemas Realizado por Objetos del Dominio de Solución Implementado por Verificado por class... class... class... Código Fuente? class...? Modelo de Caso de Pruebas

14 Actividades de Ciclo de Vida del Software Elicitación de Requerimientos Análisis Diseño de Sistema Diseño Detallado Implementación Testing Expresado en términos de Estructurado por Implementad o por Realizado por Verificado por Modelo de Caso de Uso Objetos de Dominio de Aplicación Subsistemas Objetos del Dominio de Solución class... class... class... Código Fuente? class...? Modelo de Caso de Pruebas

15 Necesidad vs. Solución

16 Qué son los Requerimientos? Qué deberá hacer el sistema? Con qué condiciones y restricciones deberá hacerlo? Qué cualidades o atributos deberá poseer el sistema? Rational define requerimiento como: Una condición o capacidad que el sistema (a construir) debe cumplir

17 Determinación de Requerimientos Fuentes: Documentación. Expertos. Técnicas Cuestionarios Entrevistas Talleres Prototipos

18 Tipos de Requerimientos Requerimientos Funcionales Describe las interacciones entre el sistema y su ambiente, independiente de la implementación Un usuario debe ser capaz de definir un nuevo juego Requerimientos No Funcionales Aspectos no relacionados directamente al comportamiento funcional El tiempo de respuesta debe ser menor a 1 seg Constraints Impuesto por el cliente o el ambiente El lenguaje de implementación debe ser Java También llamados Pseudo-requerimientos.

19 Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales Describe tareas del usuario que el sistema necesita soportar Expresado como acciones Recomendar una nueva liga Planificar un torneo Notificar a un grupo de interés Requerimientos No funcionales Describe propiedades del sistema o el dominio Expresado como constraints o aserciones negativas Todas las entradas de usuario deberían ser detectadas dentro de 1 seg Una interrupción del sistema no debería resultar en perdida de datos.

20 Tipos de Requerimientos

21 Requerimientos: Clasificación de uso común

22 Requerimientos: Categorías FURPS+

23 Requerimientos: Categorías FURPS+

24 Tipos de Requerimientos No Funcionales Usabilidad Confiabilidad Robustez Seguridad Rendimiento Tiempo de Respuesta Throughput Disponibilidad Soporte Adaptabilidad Mantenibilidad Requerimientos de Calidad Implementación Interfaz Operación Packaging Legal Constraints o Pseudo-Requerimientos

25 Algunas Definiciones de Requerimientos de Calidad Usabilidad: Facilidad con la cual los actores pueden ejecutar una función en un sistema Usabilidad es uno de los términos mal usados frecuentemente ( El sistema es fácil de usar ) Usabilidad debe ser medible, de otra forma es mercadeo Ejemplo: Especificación del número de pasos (la medida) para realizar una compra en internet con un navegador web

26 Requerimientos: Categorías FURPS+

27 Algunas Definiciones de Requerimientos de Calidad Robustez: La habilidad de un sistema de mantener una función Incluso si el usuario introduce una entrada errónea Incluso si hay cambios en el ambiente Ejemplo: El sistema puede tolerar temperaturas hasta 90 C

28 Requerimientos: Categorías FURPS+ Frecuencia y severidad de fallas Facilidades de recuperación

29 Algunas Definiciones de Requerimientos de Calidad Disponibilidad: El radio del tiempo de funcionamiento esperado de un sistema con respecto al agregado del tiempo de funcionamiento e inactivo esperado Ejemplo: El sistema no está inactivo más de 5 min por semana

30 Requerimientos: Categorías FURPS+ Condiciones impuestas a otros requerimientos y son tales como: Velocidad Eficiencia Disponibilidad Tiempo de Respuesta Tiempo de Recuperación Uso de recursos

31 Requerimientos: Categorías FURPS+ Adaptabilidad Mantenibilidad Compatibilidad Configurabilidad Instalabilidad

32 Requerimientos: Categorías FURPS+

33 Requerimientos: Categorías FURPS+ Especifica restricciones de codificación o de construcción del sistema: Estándares requeridos Lenguajes de implementación Políticas para la integridad de Bases de Datos

34 Requerimientos: Categorías FURPS+ Especifica: Elemento externo con el que el sistema debe interactuar Restricciones o formatos, tiempos u otros factores usados en tales interacciones

35 Tarea Buscar las definiciones restantes de los requerimientos no funcionales e interiorizarlos Entender su significado y alcance (su aplicabilidad).

36 Requerimientos No Funcionales: Ejemplos Espectadores deben ser capaces de ver un juego sin registro previo y sin previo conocimiento del juego. Requerimiento de Usabilidad El sistema debe soportar 10 torneos paralelos Requerimiento de Rendimiento El operador debe ser capaz de añadir nuevos juegos sin modificaciones al sistema existente. Requerimiento de Soporte

37 Escenarios: Incendio en una Tienda Bob, un policía, va manejando por la calle principal en su carro y nota que sale humo de una tienda. Su compañera, Alicia, reporta la emergencia desde una computadora portátil en el carro. Alicia introduce la dirección del edificio en su computadora, una breve descripción de su ubicación, y un nivel de emergencia. Ella confirma su reporte y espera por la aprobación por parte del sistema. Juan, el responsable, es alertado de la emergencia por un beep de su estación. El revisa la información enviada por Alicia y aprueba el reporte. Juan ubica una unidad y envía el Tiempo Estimado de LLegada (TELL) a Alicia. Alicia recibe la aprobación y el TELL.

38 Observaciones sobre el escenario del incendio en la tienda Escenario concreto Describe una sola instancia de reporte del incidente. No describe todas las posibles situaciones en la cual un incendio es reportado. Actores Participantes Bob, Alicia y Juan

39 Otras Posibilidades de escenarios para el Sistema de Manejo de Incidentes Qué se necesita para reportar un incidente de un Gato en un árbol? ( Pasa en Venezuela?) Quién está involucrado en el reporte del incidente? Qué hace el sistema, si ningún policía está disponible? Si el carro de policía se accidenta en el camino al incidente de un Gato en un árbol? Qué necesitas hacer si el incidente Gato en un árbol se convierte en un incidente de Abuela que ha caído por las escaleras? Puede el sistema lidiar con incidentes simultáneos reportando Gato en un árbol y el incendio en la tienda?

40 Después que los escenarios son formulados Encontrar todos los casos de uso en el escenario que especifica todas las instancias de cómo reportar un incendio y modelarlas en un modelo de caso de uso Ejemplo: Reportar la Emergencia en el primer párrafo del escenario es un candidato para un caso de uso Luego añadir más detalles a cada uno de esos casos de uso describiendo: 1.Nombre del caso de uso 2.Actores Participantes 3.Describir la pre-condición 4.Describir el flujo de eventos 5.Describir la post-condición 6.Describir excepciones 7.Describe requerimientos de calidad (requerimientos no funcionales).

41 Modelo de Caso de Uso Un caso de uso es un flujo de eventos en el sistema, incluyendo la interacción con actores Un CU especifica una secuencia de acciones, incluyendo sus variantes, que el sistema puede realizar y que produce un resultado observable válido para un actor particular. Cada caso de uso tiene un nombre Cada caso de uso tiene una condición de finalización Notación gráfica: Un ovalo con el nombre del caso de uso ReportEmergency Modelo de Caso de Uso: El conjunto de todos los casos de uso especificando la funcionalidad completa del sistema

42 Modelo de Caso de Uso para Manejo de Incidentes <<initiates>> <<initiates>> FieldOfficer ReportEmergency Dispatcher <<initiates>> OpenIncident AllocateResources

43 Modelo de Caso de Uso Describe lo que el sistema debe hacer y bajo que restricciones Captura los requerimientos funcionales y el ambiente del sistema Permite comprender y describir los requerimientos del sistema. Muestra un conjunto de casos de uso y actores con una asociación entre cada par actor/caso de uso. Rational define un caso de uso como un conjunto de escenarios de caso de uso, en el que cada escenario es una secuencia de acciones realizadas por el sistema y que conducen a un resultado de valor observable para un actor particular

44 UML: Primer Paso Diagramas de casos de uso Describe el comportamiento funcional del sistema como es visto por el usuario Diagramas de Clases Describe la estructura estática del sistema: Objetos, atributos, asociaciones Diagramas de Secuencia Describe el comportamiento dinámico entre objetos del sistema Diagramas de Estados Describe el comportamiento dinámico de un objeto individual Diagramas de Actividad Describe el comportamiento dinámico de un sistema, en particular el workflow.

45 UML Diagramas de Caso de Uso Pasajero ComprarTicket Usado durante la elicitación y análisis de requerimientos para representar comportamiento externo ( visible desde afuera del sistema ) Un Actor representa un rol, es decir, un tipo de usuario del sistema Un caso de uso representa una clase de funcionalidad provista por el sistema Modelo de caso de uso: El conjunto de todos los casos de uso que describen completamente la funcionalidad del sistema.

46 Actores Pasajero Nombre Un actor es una entidad externa que interactúa (comunica) con el sistema: Usuario Sistema Externo (Otro sistema) Ambiente físico (por ejemplo, clima) Un actor tiene un nombre único y una descripción opcional Ejemplos: Descripción Opcional Pasajero: Una persona en el tren Satélite GPS: Un sistema externo que provee las coordenadas GPS.

47 Actores Pasajero Usa el sistema cuando interactúa con el CU Inicia la ejecución del CU. ComprarTicket

48 Caso de Uso ComprarTicket Un caso de uso representa una clase de funcionalidad provista por el sistema Los casos de uso pueden ser descritos textualmente, con un enfoque sobre el flujo de eventos entre el actor y el sistema La descripción textual del caso de uso consiste de 7 partes: 1. Nombre único 2. Actores participantes 3. Pre-Condición 4. Post-Condición 5. Flujo de eventos 6. Excepciones 7. Requerimientos especiales.

49 Ejemplo de la Descripción Textual del Caso de Uso Pasajero ComprarTicket 1. Nombre: Comprar ticket 2. Actor Participante : Pasajero 3. Pre-Condición: Pasajero permanece en frente del distribuidor del ticket Pasajero tiene suficiente dinero para comprar el ticket 4. Post-Condición: El pasajero tiene el ticket 5. Flujo de eventos: 1. El Pasajero selecciona el número de zonas a viajar 2. El Distribuidor del ticket muestra la cantidad a pagar 3. El Pasajero inserta el dinero, al menos la cantidad a pagar 4. El Distribuidor del ticket devuelve el cambio 5. El Distribuidor del ticket emite el ticket 6. Requerimientos especiales: Ninguno.

50 Los Casos de Uso pueden estar relacionados Relaciones entre actores y CU Asociación Relaciones entre casos de uso Relación Extends Para representar casos de uso algunas veces invocados o una funcionalidad excepcional Relación Includes Para representar comportamiento funcional común a mas de un caso de uso. Relación de Generalización Relaciones entre actores Generalización

51 Relación <<extends>> La relación <<extends>> modela casos excepcionales o algunas veces invocados Pasajero Comprar Ticket La dirección de una relación <<extends>> es hacia el caso de uso extendido Los casos de uso que representan flujos excepcionales pueden extender más de un caso de uso. <<extends>> Cancelar Compra

52 Relación <<extends>> Extension Points: el caso de uso podrá ejecutarse una vez alcanzado el (los) punto de extensión indicado(s). Ir al Cine Extension Points Después de entrar al cine Cliente <<extend>> Comprar Cotufas

53 La relación <<includes>> Pasajero Comprar Ticket <<includes>> Comprar MultiAbono <<includes>> La relación <<includes>> representa funcionalidad cómun necesaria es mas de un caso de uso <<includes>> permite reusar un caso de uso, no es porque es una excepción La dirección de una relación <<includes>> es contraria a la relación <<extends>>. Recoger Boleto

54 Modelos de Caso de Uso pueden ser empaquetados Clasificador Caso de Uso Actor. Límite del Sistema

55 UML 1 usó paquetes Paquete Course Instructor GiveLecture HoldExercise Student Teaching Assistent DoHomework

56 Cómo encontrar Casos de Uso Seleccionar un escenario Discutir en detalle con el usuario para entender la interacción del usuario con el sistema Seleccionar muchos escenarios para definir el alcance del sistema. Discutir el alcance con el usuario Usar prototipos ilustrativos (mock-ups) como soporte visual Descubrir que hace el usuario Observación de tareas Cuestionarios

57 Ejemplo de Caso de Uso: ReportEmergency 1. Nombre de caso de uso: ReportEmergency 2. Actores Participantes: Oficial, Responsable 3. Pre-Condición: El oficial está conectado al Sistema FRIEND 4. Flujo de Eventos: próxima lámina 5. Post-Condición: El oficial ha recibido una aprobación del sistema y la respuesta a la emergencia o el oficial ha recibido una explicación indicando porque no puede ser procesada la emergencia 6. Excepciones: El oficial es notificado inmediatamente si la conexión entre el terminal y la central se pierde 7. Requerimientos de Calidad: El reporte del oficial es aprobado dentro de 30 seg.

58 Ejemplo de Caso de Uso: ReportEmergency 4. Flujo de Eventos: 1. El oficial completa el formulario, seleccionando el nivel de emergencia, tipo, ubicación, y una breve descripción de la situación. El oficial también describe una respuesta a la situación de emergencia. Una vez que el formulario es completado, el oficial envía el formulario, y el Responsable es notificado. 2. El responsable crea un Incidente en la base de datos invocando al caso de uso OpenIncident. El selecciona una respuesta y aprueba el reporte. 3. El oficial recibe la aprobación y la respuesta seleccionada.

59 Otro Ejemplo: Ubicar un Recurso Glosario: Supervisor de Campo: Este es el oficial en el sitio de emergencia Encargado de Ubicar Recursos: Es el responsable de asignar y liberar recursos manejados por el sistema FRIEND Responsable: Un Responsable introduce, actualiza, y elimina Incidentes de Emergencia, Acciones, y Solicitudes en el sistema. El Responsable también cierra Incidentes de Emergencia Oficial de Campo: Reporta accidentes desde el sitio de emergencia

60 Ubicar un Recurso 1. Nombre de caso de uso: AllocateResources 2. Actores Participantes: Oficial de Campo, Responsable, Encargado de Ubicar Recurso, Supervisor de Campo 3. Pre-Condición : El Encargado de Ubicar Recurso ha seleccionado un recurso disponible 4. Flujo de Eventos : 1. El Encargado de Ubicar Recurso selecciona un Incidente 2. El Recurso es asignado al Incidente 5. Post-Condición : El caso de uso termina cuando el recurso es asignado El Recurso asignado no está disponible a otras solicitudes. 6. Requerimientos especiales: El Supervisor de campo es responsable de manejar los Recursos.

61 Orden de los pasos cuando se describen los casos de uso Primer paso: Nombre de caso de uso Nombre de caso uso: ReportEmergency Segundo paso: Encontrar los actores Generalizar los nombres concretos del escenario a actores participantes Actores Participantes: Oficial de Campo (Bob y Alicia en el escenario) Responsable (Juan en el escenario) Tercer paso: Concentrarse en el flujo de eventos Uso informal del lenguaje natural

62 Otro Ejemplo de CU Flujo de Eventos El Cliente del Banco especifica una Cuenta y provee las credenciales al Banco para probar que es la persona autorizada para acceder a la Cuenta del Banco El Cliente del Banco especifica la cantidad de dinero que quiere retirar El Banco chequea si la cantidad es consistente con las reglas del Banco y el estado de la cuenta del Cliente. Si es el caso, el Cliente recibe el dinero en efectivo.

63 Atributos de CU Nombre de Caso de Uso: Withdraw Money Using ATM Actor Participante: Cliente Pre-condición: El Cliente ha abierto una Cuenta con el Banco Y el Cliente ha recibido una Tarjeta y un PIN Post-condición: El Cliente ha solicitado efectivo O el Cliente recibe una explicación del ATM del por qué el efectivo no pudo ser entregado.

64 Flujo de Eventos: A Request-Response Interaction between Actor and System Pasos del Actor 1. El Cliente introduce la tarjeta en el ATM 3. El cliente marca su PIN 5. El Cliente selecciona una cuenta Pasos del Sistema 2. El ATM solicita la entrada de un PIN de cuatro dígitos 4. Si existen diferentes cuentas afiliadas en la tarjeta, el ATM ofrece una alternativas de los números de cuenta para la selección del Cliente 6. El ATM solicita la cantidad a ser retirada 7. El Cliente introduce una cantidad 8. El ATM entrega el dinero y un recibo, y termina la interacción.

65 Excepciones de CU Pasos del Actor 1. El Cliente introduce su tarjeta en el ATM.[Tarjeta Inválida] 3. El Cliente marca su PIN. [PIN Inválido] 5. El Cliente selecciona una cuenta. 7. El Cliente introduce una cantidad. [Cuenta Sobregirada] 1a) [Tarjeta Inválida] El ATM entrega la tarjeta y detiene la interacción. 3a)[PIN Inválido] El ATM notifica la falla y permite una segunda oportunidad así como cancelar el caso de uso completo. Después de 3 intentos, notifica la posible retención de la tarjeta. Después del 4to intento retiene la tarjeta y detiene la interacción. 7a)[Cuenta Sobregirada] El ATM notifica la falla y el limite disponible y permite un segundo intento así como cancelar el caso de uso completo.

66 De CU a Objetos Nivel 1 CU Nivel Top Nivel 2 Nivel 2 CU Nivel 2 Nivel 3 Nivel 3 Nivel 3 CU Nivel 3 Nivel 4 Nivel 4 Operaciones A B A y B se denominan Objetos Participantes

67 CU usados por más de un Objeto Nivel 1 CU Nivel Top Nivel 2 Nivel 2 CU Nivel 2 Nivel 3 Nivel 3 Nivel 3 CU Nivel 3 Nivel 4 Nivel 4 Operaciones A B Objetos Participantes

68 Guías para Expresar CU (1) Nombre Usar el verbo en modo infinitivo para nombrar el CU Debe indicarse el complemento Ejemplos: Longitud Solicitar Reunión, Planificar Reunión, Proponer Fecha Alternativa Una descripción de CU no debe exceder de 1-2 paginas. Si es mas larga, usar relaciones include Un CU debe describir un conjunto completo de interacciones.

69 Guías para Expresar CU(2) Flujo de eventos: Usar voz activa. Los pasos deben empezar con El Actor o El Sistema La relación causal entre los pasos debe ser clara Todos los flujos de eventos deben estar descritos (No solamente el flujo principal del evento) Los limites del sistema deben estar claros. Los componentes externos al sistema deben estar descritos como tal Definir los términos importantes en el glosario.

70 Flujo de Eventos: Usar Indentación para mostrar la Interacción entre el Actor y el Sistema 1. El Cliente introduce la tarjeta en el ATM 2. El ATM solicita la entrada de un PIN de cuatro dígitos 3. El cliente marca su PIN 4. Si existen diferentes cuentas afiliadas en la tarjeta, el ATM ofrece una alternativas de los números de cuenta para la selección del Cliente 5. El Cliente selecciona una cuenta 6. El ATM solicita la cantidad a ser retirada 7. El Cliente introduce una cantidad 8. El ATM entrega el dinero y un recibo, y termina la interacción.

71 Ejemplo de un CU mal escrito El conductor llega hasta la barra del estacionamiento, el conductor recibe un ticket del distribuidor, la barra se levanta, el conductor sigue manejando. Qué hay de malo con este CU?

72 Ejemplo de un CU mal escrito El conductor llega hasta la barra del estacionamiento, el conductor recibe un ticket del distribuidor, la barra se levanta, el conductor sigue manejando. No está claro cual acción produjo que el ticket se emitiera Debido a la forma pasiva, no es claro quien levantó la barra: El conductor? El computador? El responsable de la barra? No es una transacción completa Una transacción completa debe describir también el pago del estacionamiento y la salida del estacionamiento.

73 Como escribir un CU? (Resumen) Nombre de CU Actores Descripción de los Actores involucrados en el CU Pre-condición Este CU comienza cuando Flujo de Eventos Forma libre, lenguaje natural informal Post-condición Este CU termina cuando Excepciones Describe que sucede cuando las cosas van mal Requerimientos de Calidad Requerimientos No funcionales, Constraints

74 Asociaciones de CU Dependencias entre los CU son representados con asociaciones de casos de uso Asociaciones son usadas para reducir la complejidad Descomponer un gran CU en CU mas cortos Separar flujos de eventos alternos Refinar casos de uso abstractos Tipos de asociaciones de casos de uso Includes Extends Generalización

75 <<include>>: Descomposición Funcional Problema: Una función en el problema original es demasiado compleja Solución: Describir la función como la agregación de un conjunto de funciones mas simples. El CU asociado es descompuesto en CU mas cortos ManageIncident <<include>> CreateIncident HandleIncident CloseIncident

76 <<include>>: Reusar Funcionalidad Existente Problema: Hay solapamientos entre CU?. Cómo reusar flujos de eventos en vez de duplicarlos? Solución: La relación includes de un CU A a un CU B indica que una instancia del CU A ejecuta todo el comportamiento descrito en el CU B ( A delega a B ) Ejemplo: El CU ViewMap describe el comportamiento que es usado por el CU OpenIncident ( ViewMap es factorizado) <<include>> OpenIncident ViewMap CU Base <<include>> AllocateResources CU Proveedor

77 <<extend>> Asociacion para CU Problema: La funcionalidad en el problema original necesita ser extendida. Solución: Una relación extend de un CU A a un CU B Ejemplo: ReportEmergency está completo por si mismo, pero puede ser extendido por el CU Help para un escenario en el cual el usuario requiere ayuda FieldOfficer ReportEmergency CheckHelp <<extend>>

78 Generalizacion en CU Problema: Se quiere factorizar comportamiento común (pero no idéntico). Solución: Los CU hijos heredan el comportamiento y el significado del CU padre y añade o sobrescribe algún comportamiento. Ejemplo: ValidateUser es responsable de verificar la identidad del usuario. El cliente podría requerir dos realizaciones: CheckPassword y CheckFingerprint CU Hijo CU Padre ValidateUser CheckPassword CheckFingerprint

79 Caso de Estudio: El Sistema de Revisión de Conferencias Presentado en IWWOST 2001 El propósito del sistema es soportar el proceso de envío, evaluación y selección de trabajos para una conferencia.

80 Actores I PC Chair Crea la conferencia Determina tópicos y temas de la conferencia Establece el comité del Programa Define la lista final de trabajos aceptados y rechazados Define las fechas limites de la conferencia: envío, revisión, y notificación.

81 Actores II Miembro PC Evaluar un conjunto de trabajos asignados Indicar otra persona como revisor de un trabajo Notificar al PC Chair de la lista final de trabajos aceptados Revisor Responsable de revisar un trabajo Autor Enviar un trabajo a la conferencia Miembros PC y Revisores pueden ser también Autores, y deben tener diferentes Ids para cada rol

82 Funciones I: Envío de Trabajo Cualquier autor registrado puede enviar un trabajo El autor debe registrar: el titulo, el resumen, el tópico de la conferencia, y un conjunto de temas elegidos de una lista previamente determinada por el PC Chair El sistema, después de chequear los registros de los autores, asigna un ID al nuevo trabajo, y permite al usuario enviarlo cargando un archivo En cualquier momento, un autor se le permite chequear los datos sobre sus trabajos enviados. Hasta la fecha limite de envío, el autor se le permite también sustituir el archivo ya cargado por uno nuevo, o cambiar cualquiera de los datos sobre el trabajo

83 Funciones II: Asignación de trabajos a Miembros PC El PC Chair puede indicar conflictos de interés potencial entre miembros PC y trabajos enviados Una vez que la fecha limite de envío ha sido alcanzada Los miembros PC pueden indicar su interés y conflictos de interés con algunos trabajos En caso de un conflicto de interés, el miembro PC no podrá ver ninguna información sobre el trabajo El PC Chair asigna trabajos a miembros PC para revisión, un mensaje de correo electrónico con la lista de trabajos, y un URL a una pagina donde puede acceder los trabajos asignados

84 Funciones III: Introduciendo una Revisión Un miembro PC, o un Revisor, puede introducir una revisión para un trabajo asignado La revisión es introducida accediendo un formulario que contiene todos ítems de evaluación Un miembro PC puede ver otras revisiones (introducidas por otros) para cualquiera de los trabajos que esta revisando, pero solo después que ha introducido su propia revisión El PC Chair tiene acceso completo a todos los trabajos y a todas las revisiones

85 Funciones IV: Elección de Trabajos Aceptados y Rechazados Una vez que la fecha limite de revisión ha sido alcanzada, el proceso de revisión es cerrado El PC Chair, tomando en cuenta las recomendaciones de los miembros PC y revisores, elije los trabajos que serán aceptados y rechazados Una vez que el proceso es marcado como finalizado por el PC Chair, el sistema envía un mensaje de notificación a los autores del trabajo, el cual incluye las partes apropiadas de las revisiones enviadas por los miembros PC y revisores

86 Resumen Escenarios: Una gran forma de establecer comunicación con el cliente Casos de Usos Abstracciones de escenarios CU son un puente hacia la transición entre requerimientos funcionales y objetos.